CAP con elementos Fiori: efectos secundarios, acciones personalizadas, expresiones dinámicas

Introducción

En una asignación reciente, tuve la oportunidad de usar el modelo de programación de aplicaciones en la nube y los elementos de Fiori para diseñar y crear una aplicación lista para la empresa. Usé algunos conceptos como expresiones dinámicas, efectos secundarios y acciones personalizadas en páginas de objetos. Sin embargo, encontrar material apropiado o referencias con ejemplos y comprender los conceptos requirió mucho tiempo. Intentaré describir brevemente estas ideas en esta publicación de blog para que otros puedan beneficiarse y ahorrar tiempo.

Breve explicación del escenario POC y sus recursos

Utilizaremos el proyecto de ejemplo «cap-fe-se-ca-de» que publiqué en GitHub aquí para explicar los temas. Repasemos rápidamente el proyecto y algunos de sus archivos clave.

	Carpeta o Archivo	Objetivo
	aplicación/	Esto tiene 2 interfaces de interfaz de usuario, es decir, Clientes y Pedidos.
	db/	El modelo de datos se define en schema.cds
	srv/	Los servicios se definen en service.cds y la lógica se agrega a través de service.js. También capacidades.cds agrega/restringe diferentes capacidades de los servicios
	aplicación/pedidos	Aplicación de interfaz de usuario basada en Fiori Elements para pedidos anotaciones.cds: contiene anotaciones para la página de lista y la página de objetos anotaciones_se.cds: contiene anotaciones relacionadas con los efectos secundarios anotaciones_ca_de.cds: contiene anotaciones relacionadas con acciones personalizadas y expresiones dinámicas

Las aplicaciones «Clientes» y «Pedidos» en la carpeta de la aplicación se crearon con Fiori Elements. Para comprender mejor los temas antes mencionados, nos concentraremos en la aplicación Pedidos. La primera vista en la aplicación Pedidos es una Página de lista y la segunda vista, que es la vista de detalles, es una Página de objeto, como se ilustra a continuación:

Pedidos – Página de lista	Órdenes – Objeto Pagmi

Concepto-1: Efectos secundarios

Si un usuario modifica el contenido de un campo o realiza una acción, esta modificación puede tener un impacto en otros campos de la interfaz de usuario. Este comportamiento del sistema se denomina efecto secundario.

ejemplo: en orden, si ingresa cantidad y precio, el valor total se actualiza automáticamente. Este comportamiento se denomina efecto secundario.

Hay diferentes variaciones de los efectos secundarios. Exploremos uno por uno usando el archivo annotations_se.cds en la aplicación Pedidos.

using orderservice as service from '../../srv/service';
annotate service.Orders @(Common : {
    SideEffects #CustomerChanged : {
        SourceProperties : ['customer_ID'],
        TargetEntities   : [customer, customer.addresses]
    }
});

annotate service.OrderItems @(Common : {
    SideEffects #ProductChanged  : {
        SourceProperties : ['product_id'],
        TargetProperties : ['price', 'currency_code', 'netprice']
    }
});

annotate service.OrderItems @(Common : {
    SideEffects #QuantityChanged : {
        SourceProperties : ['quantity'],
        TargetProperties : ['netprice']
    }
});

this.before('PATCH', OrderItems, async req => {

  let productInfo, price, quantity, dbItemInfo;

  //When product is available, fill price and currency
  if (req.data.product_id != undefined && req.data.product_id != null) {
    productInfo = await cds.read(Products).byKey(req.data.product_id);
    req.data.price = productInfo.price;
    req.data.currency_code = productInfo.currency_code;
  }

  // Calculate Net Price
  dbItemInfo = await cds.read(OrderItems.drafts).where({ ID: req.data.ID });
  req.data.price > 0 ? price = req.data.price : price = dbItemInfo[0].price;
  req.data.quantity > 0 ? 
  quantity = req.data.quantity : quantity = dbItemInfo[0].quantity;
  if (price > 0 && quantity > 0) {
    req.data.netprice = price * quantity;
    req.data.netprice = Math.round((req.data.netprice + Number.EPSILON)*100);
    req.data.netprice = req.data.netprice / 100;
  }

});

annotate service.Orders @(Common : {
    SideEffects #ItemChanged     : {
        SourceEntities   : [items],
        TargetProperties : ['totamount', 'currency_code']
    }
});

this.after('PATCH', OrderItems, async data => {

  let orderInfo = { totamount: 0 };
  let result = await cds.read(OrderItems.drafts)
                        .where({ ID: data.ID }).columns(['order_ID']);
  let dbItemInfos = await cds.read(OrderItems.drafts)
                             .where({ order_ID: result[0].order_ID });
  for (let i = 0; i < dbItemInfos.length; i++) {
    if (dbItemInfos[i].netprice > 0) {
      orderInfo.totamount = orderInfo.totamount + dbItemInfos[i].netprice;
    }
    orderInfo.currency_code = dbItemInfos[i].currency_code;
  }
  await cds.update(Orders.drafts, result[0].order_ID).set(orderInfo);

});

Concepto-2: Función de valores predeterminados

Los valores predeterminados se pueden proporcionar utilizando una «Función de valor predeterminado» al crear una nueva entidad o elemento.
Por ejemplo, el estado inicial de un pedido siempre se establece en «Abierto» cuando se crea.

La anotación para proporcionar ‘DefaultValueFunction’ es como se muestra a continuación:

annotate service.Orders with @(
    Common.DefaultValuesFunction : 'getOrderDefaults'
);

Aquí, ‘getOrderDefaults‘ es una función vinculada de la entidad de pedidos bajo el servicio de pedidos. Se define en el archivo service.cds y service.js.

//Definition [service.cds]
function getOrderDefaults() returns Orders;

//Implementation [service.js]
this.on('getOrderDefaults', async req => {
  return {status: 'Open'};
});

Concepto-3: Acciones personalizadas

El estado inicial de un pedido es ‘Abierto’. Podemos definir una acción personalizada para cambiar el estado de ‘Abierto’ a ‘En proceso’ y viceversa.

Se proporcionan dos acciones vinculadas y su lógica correspondiente en service.cds y service.js respectivamente, como se muestra a continuación:

//Definition [service.cds]
entity Orders    as projection on db.Orders actions {
    action setOrderProcessing();
    action setOrderOpen(); 
};

//Implementation [service.js]
this.on('setOrderProcessing', Orders, async req => {
  await cds.update(Orders, req.params[0].ID).set({status: 'In Process'});
});

this.on('setOrderOpen', Orders, async req => {
  await cds.update(Orders, req.params[0].ID).set({status: 'Open'});
});

Estas 2 acciones se pueden agregar en la interfaz de usuario como botones usando anotaciones como se proporciona en el archivo annotations_ca_de.cds.

annotate service.Orders with @(UI.Identification : [
    {
        $Type         : 'UI.DataFieldForAction',
        Label         : 'Set to In Process',
        Action        : 'orderservice.setOrderProcessing'
    },
    {
        $Type         : 'UI.DataFieldForAction',
        Label         : 'Set to Open',
        Action        : 'orderservice.setOrderOpen'
    }
]);

Concepto-4: Expresiones Dinámicas

Las expresiones dinámicas son pequeñas lógicas definidas en la anotación para controlar el comportamiento de la interfaz de usuario.

Ejemplo: si el estado del pedido es Abierto, entonces solo se ve el botón ‘Establecer en proceso’ y si el estado del pedido es En proceso, solo se ve el botón ‘Establecer en abierto’. Para lograr esto, podemos usar expresiones dinámicas.

Nota 1: OData admite expresiones dinámicas en las anotaciones. En CDS, estas expresiones dinámicas se proporcionan mediante representaciones JSON. Para obtener más información, consulte este documento.

annotate service.Orders with @(UI.Identification : [
    {
        $Type         : 'UI.DataFieldForAction',
        Label         : 'Set to In Process',
        Action        : 'orderservice.setOrderProcessing',
        ![@UI.Hidden] : {$edmJson : {$Ne : [{$Path : 'status'}, 'Open']}}
    },
    {
        $Type         : 'UI.DataFieldForAction',
        Label         : 'Set to Open',
        Action        : 'orderservice.setOrderOpen',
        ![@UI.Hidden] : {$edmJson : {$Eq : [{$Path : 'status'},'Open']}}
    }
]);

Criticality: {$edmJson :{$If :[{$Eq :[{$Path : 'status'},'Open']}, 1, 3]}}

Una nueva expresión dinámica verifica si el estado está abierto y luego devuelve 1; de lo contrario, devuelve 3 para Criticidad.

Concepto-5: Acciones personalizadas con efectos secundarios

Como se explicó en el concepto anterior, hemos utilizado dos acciones para cambiar el estado del pedido. Sin embargo, una vez que se ejecuta la acción, el campo de estado en la interfaz de usuario también debería cambiar instantáneamente. Para lograr esto, podemos definir efectos secundarios para acciones personalizadas como se muestra a continuación.

En este caso, las anotaciones de efectos secundarios se proporcionan en el archivo service.cds.

entity Orders    as projection on db.Orders actions {

    @(  cds.odata.bindingparameter.name : '_it',
        Common.SideEffects : {TargetProperties : ['_it/status']}   )
    action setOrderProcessing();

    @(  cds.odata.bindingparameter.name : '_it',
        Common.SideEffects : {TargetProperties : ['_it/status']}   )
    action setOrderOpen();
    
};

Conclusión

Juntos, el modelo de programación de aplicaciones en la nube y los elementos Fiori mejoran la experiencia del desarrollador al mismo tiempo que aumentan la productividad y aceleran el desarrollo de aplicaciones listas para la empresa.

Se puede encontrar más información sobre Fiori Elements con el modelo de programación de aplicaciones en la nube aquí. Puede seguir mi perfil para recibir notificaciones de la próxima publicación de blog sobre CAP o Fiori Elements. Siéntase libre de proporcionar cualquier comentario que tenga en la sección de comentarios a continuación y haga sus preguntas sobre el tema en la comunidad de sap usando este Enlace.