Introducción

Esta publicación de blog sirve como seguimiento de la siguiente publicación anterior:

CAP con Fiori Elements: Acciones en el informe de lista/página de objetos usando anotaciones – Parte 1

En esta publicación de blog, describí mis observaciones sobre los diversos tipos de acciones que se pueden lograr mediante la definición y las anotaciones del servicio.

Explicación del escenario POC y sus recursos

Usaremos el proyecto de muestra. “acciones-op-cap-fe-lr” que he compartido en GitHub aquí para explicar los conceptos. Examinemos brevemente el proyecto y algunos de sus archivos esenciales.

Estructura del proyecto	Carpeta o archivo	Objetivo
	base de datos/	El modelo de datos se define en esquema.cds
	srv/	Los servicios se definen en servicio.cds Las capacidades de los servicios se definen en anotaciones.cds
	aplicación/	Contiene la aplicación UI.
	aplicación/anotaciones	contiene todos los archivos de anotaciones.
	anotaciones.cds	anotaciones para enumerar vistas de informes
	acciones-genéricas.cds	anotaciones para acciones genéricas (explicadas en la sección 1 de Explicación Detallada)
	acciones-determinantes-globales.cds	anotaciones para acciones globales y determinantes
	acciones-de-grupo-de-campo.cds	anotaciones para acciones en el grupo de campos
	tabla-acciones.cds	anotaciones para acciones en la tabla
	chart-actions.cds	anotaciones para acciones en el gráfico
	variedades-de-accion.cds	anotaciones para tipos de acciones

Servicio “cap_fe_lr_op_actions_service» proporciona el siguiente conjunto de datos: raíces, elementos, Categorías, CriticidadesMuestras.

Tenga en cuenta que en esta publicación de blog, mi énfasis está en ilustrar la funcionalidad de presentar tablas en varias configuraciones. Vale la pena señalar que el servicio utilizado con fines de demostración puede no ser perfecto y se utiliza únicamente para explicar las funcionalidades.

Explicación detallada

Ahora, exploremos varios tipos de acciones que se pueden incorporar mediante anotaciones. Para ilustrar, usaremos la vista Muestras del informe de lista dentro de la aplicación (marcado arriba).

• Acción crítica
• Acción con diálogo con entrada de texto
  • Las acciones con un cuadro de diálogo son acciones que requieren entrada adicional del usuario, por ejemplo, un comentario. El sistema mostrará un cuadro de diálogo que contiene uno o más campos de entrada para que el usuario ingrese los detalles necesarios.
  • Para implementar una acción con un diálogo, puede mejorar su acción agregando parámetros de entrada adicionales como se muestra a continuación:

    type inText : {
      comment: String;
    };
    
    entity Samples as projection on db.Samples actions {
      action sba_action_text(text:inText:comment);
    };​​

  • También es posible asignar un texto de etiqueta a la entrada incluyendo una etiqueta en el tipo:

    annotate service.inText:comment with @Common.Label :'MultiLine Input Text';

  • Si bien las entradas de texto/cadena generalmente se muestran como un campo de entrada de una sola línea, puede convertirlas en varias líneas aplicando la siguiente anotación:

    annotate service.inText:comment with @UI.MultiLineText:true;​

  • Resultado:
    
• Acción con entrada múltiple
  • Las acciones pueden tener diferentes tipos de entrada según el tipo de parámetros de entrada definidos para la acción en la definición del servicio.
  • Veamos un ejemplo:

    /*=======>> Action Definition <<=======*/
    type inComplexObject : {
      comment : String(50);
      date    : Date;
      datetime: DateTime;
      confirm : Boolean;
      value   : Integer;    
    };
    
    action sba_action_complex(
        aprcomment  :inComplexObject:comment,
        aprdate     :inComplexObject:date,
        aprdatetime :inComplexObject:datetime,
        aprconfirm  :inComplexObject:confirm
    );​

    /*==========>> Annotations <<==========*/
    annotate service.inComplexObject {
      comment   @Common.Label: 'Comment';
      date      @Common.Label: 'Date of Approval';
      datetime  @Common.Label: 'Time of Processing';
      confirm   @Common.Label: 'Confirmation';
    };

    La definición de acción y las anotaciones anteriores proporcionarán el siguiente resultado:
    
  • Nota: El tipo de control que se representará depende del tipo de datos del parámetro de importación para la acción en la definición del servicio.
• Acción con entrada obligatoria y predeterminada
  • También es posible hacer que algunos parámetros de importación de acción sean obligatorios y también proporcionar valores predeterminados.
  • Aquí hay un ejemplo:

    /*=======>> Action Definition <<=======*/  
    type inOtherObject: {
        input1  :String(50);
        input2  :String(50);
        input3  :String(50);
    };    
    
    @cds.odata.bindingparameter.name : '_it'
    action sba_action_other(
        text1 :inOtherObject:input1, 
        
        @UI.ParameterDefaultValue:'default text'
        text2 :inOtherObject:input2,
        
        @UI.ParameterDefaultValue: _it.name
        text3 :inOtherObject:input3 
    );​​

    /*==========>> Annotations <<==========*/
    annotate service.inOtherObject {
      input1  @Common.Label: 'First Input' @mandatory;
      input2  @Common.Label: 'Second Input';
      input3  @Common.Label: 'Third Input';
    };

  • Resultado:
    Si el usuario no completa el parámetro obligatorio, arroja un error como se muestra
    
  • Nota 1: el término de anotación @mandatory se utiliza para que el parámetro sea obligatorio
    Nota 2: El término de anotación @UI.ParameterDefaultValue se utiliza para proporcionar el valor predeterminado para un parámetro. También es posible utilizar el valor de una propiedad del contexto seleccionado como valor predeterminado.
  • En el ejemplo anterior, tenemos el valor de la propiedad de nombre como valor predeterminado para el tercer parámetro de entrada.
• Acción con entrada basada en DefaultValueFunction
  • Además de especificar valores predeterminados con la anotación @UI.ParameterDefaultValue, es factible recuperar valores predeterminados del servicio backend utilizando una función dentro del servicio.
  • Veamos un ejemplo

    /*=======>> Action Definition <<=======*/
    service cap_fe_lr_op_actions_service {
      type inObjectFn:{
        text1: String;
        text2: String;
      }
    
      @Common.DefaultValuesFunction: 'cap_fe_lr_op_actions_service.getDefaults'
      action sba_action_defaultfn(text1:inObjectFn:text1, 
                                @UI.ParameterDefaultValue: 'default value'
                                text2: inObjectFn:text2);
    
      function getDefaults() returns inObjectFn;
    }
    
    /*=======>> Defulat Function <<=======*/
    srv.on(["getDefaults"], async (req) => {
      return {  text1: 'default text 01', 
                text2: 'default text 02'  };
    });​​

    /*==========>> Annotations <<==========*/
    annotate service.inObjectFn {
      text1 @Common.Label: 'First Text Input';
      text2 @Common.Label: 'Second Text Input';
    }

  • Resultado:
    

  • Nota: El término de anotación @UI.ParameterDefaultValue tiene importancia sobre el valor de DefaultValuesFunction, como se desprende del ejemplo anterior para text2.
• Acción con entrada de ayuda valiosa
  • Además de la ayuda con valores predeterminada que aparece para los parámetros de importación de fecha y hora, tiene la opción de incluir sus propias ayudas con valores personalizados.
  • Veamos un ejemplo

    /*=======>> Action Definition <<=======*/  
    type inObject :{
      category    : String;
      criticality : String;
    }    
    
    action sba_action_valuehelp(
        category:inObject:category,
        criticality:inObject:criticality
    );​​

    /*==========>> Annotations <<==========*/
    annotate service.inObject {
    category @(
      Common.Label: 'Sample Category',
      Common.ValueList : {
        $Type : 'Common.ValueListType',
        CollectionPath : 'Categories',
        Parameters : [
          { $Type : 'Common.ValueListParameterInOut',
            LocalDataProperty : category,
            ValueListProperty : 'id'                       },
          { $Type : 'Common.ValueListParameterDisplayOnly',
            ValueListProperty : 'descr'                    }
        ],
        Label : 'Choose One Category'
      },
      Common.ValueListWithFixedValues : false
    );
    criticality @(
      Common.Label: 'Sample Criticality',
      Common.ValueList : {
        $Type : 'Common.ValueListType',
        CollectionPath : 'Criticalities',
        Parameters : [
          { $Type : 'Common.ValueListParameterInOut',
            LocalDataProperty : criticality,
            ValueListProperty : 'id'                       },
          { $Type : 'Common.ValueListParameterDisplayOnly',
            ValueListProperty : 'descr'                    }
        ],
        Label : 'Choose One Criticality'
      },
      Common.ValueListWithFixedValues : true
    );
    };

  • Resultado:
    
  • Nota: Las ayudas para valores se agregan al tipo de parámetro de importación mediante el término de anotación @Common.ValueList.

Funciones varias

• Manejo de mensajes
  • Hay dos formas de mostrar mensajes en la aplicación de interfaz de usuario basada en SAP Fiori Elements: tostadoras de mensajes, cuadro de diálogo de mensajes como se muestra a continuación:
    
  • La visualización de un mensaje brindis o un cuadro de diálogo depende del método utilizado en un servicio basado en CAP para comunicar el mensaje.
  • Vale la pena señalar que el uso del método req.notify produce un mensaje del sistema, mientras que otros métodos como req.info, req.warn y req.error dan como resultado cuadros de diálogo de mensajes con diferentes gravedades.

    req.notify('message to be shown on message toast');
    req.error('erroneous message shown on message dialog')​

  • Además, cuando se emplea req.info, req.warn, req.error o req.notify, solo se puede transmitir un único mensaje. Para enviar múltiples mensajes, es necesario enviar todos los mensajes del servicio usando el mensajes-sap encabezado, como se ilustra a continuación:

    srv.on("msg_trigger",async (req) => {
      req._.odataRes.setHeader('sap-messages', JSON.stringify([
        { 
          "code" : "500",
          "message" : "info: messages trigger action called!",
          "numericSeverity" : 2                            
        },
        {
          "code" : "504",
          "message" : "This can only be triggered for draft data",
          "numericSeverity" : 3
        },
        {
          "code" : "504",
          "message" : "Error happened! Contact your IT Admin",
          "numericSeverity" : 4
        }
      ]));
    });​

    Esto da como resultado el siguiente mensaje de diálogo:
    
• Criticidad de las acciones
  • Asignar un nivel de criticidad a una acción, lo que se logra configurando la propiedad «Criticalidad» dentro de la anotación, da como resultado representaciones semánticas tanto positivas como negativas.
  • Solo se admiten dos valores de criticidad: #Positivo (03), #Negativo (01)
  • Tenga en cuenta que la criticidad no es universalmente compatible con todas las acciones; su aplicabilidad se limita a acciones de tabla en línea y acciones globales/determinantes en la página del objeto.

Conclusión

En esta publicación de blog, hemos profundizado en diferentes tipos de acciones generadas en función de la definición del servicio y las anotaciones junto con el manejo de mensajes en SAP Fiori Elements.

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

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 del blog sobre CAP o Fiori Elements. No dude en proporcionar cualquier comentario que tenga en la sección de comentarios a continuación y hacer sus preguntas sobre el tema en la comunidad SAP usando este enlace.