Una breve historia

Los mensajes en ABAP, como en todos los demás lenguajes de programación, se utilizan para describir lo que sucede durante la ejecución del código para el programador o el usuario. Primero se inventaron actuando como mensajes de diálogo para mostrar información breve y manejar entradas incorrectas del usuario durante el procesamiento dynpro clásico. Aquí, una situación de excepción generalmente requería la salida directa de un mensaje al usuario. Como un buen ejemplo, se podría ejecutar el verificación de entrada dynpro de documentación ABAP. Esto muestra la forma más antigua de instrucción de mensajes en ABAP. Se cuida que la entrada se dé correctamente obligando al usuario a introducir ciertos valores en los campos. Echemos un vistazo más de cerca a una parte de este código:

  IF input1 < 50.
    MESSAGE e888(sabapdemos) WITH text-001 '50' text-002.
  ENDIF.

Después de ejecutar el programa, al presionar enter, recibió una notificación de la siguiente forma:

Este mensaje le recuerda al usuario que ingrese una cantidad correcta y, por lo tanto, cumpla con los requisitos de los mensajes en primer lugar.

En los inicios del mundo ABAP, todo solía ser programación de diálogo. Sin embargo, el concepto de mensajería posterior se adoptó para otras situaciones, como las terminaciones de programas específicos o el manejo de excepciones.

Antes de que se introdujeran las clases de excepción, se podía manejar el mensaje de error en un módulo de funciones como una excepción con texto a través de la excepción general ‘error_message’. Estas excepciones no basadas en clases también se pueden manejar en módulos de funciones, así como en definiciones de clases, definiendo una excepción y ‘aumentándola’.

Más tarde, se exigió asociar objetos con mensajes y mostrarlos usando la declaración MENSAJE. Esto estaba pensado principalmente para textos de excepción de clases de excepción. A medida que se define el concepto de clase de excepción, la pregunta principal fue cómo se pueden conectar los mensajes a las clases. Esa fue la razón por la que surgieron las interfaces de sistema IF_T100_MESSAGE y IF_T100_DYN_MSG que se pueden vincular a clases para hacer que las clases sean portadoras de mensajes. Sin embargo, esto genera complejidad debido a una doble dirección indirecta.

Los objetos IF_T100_MESSAGE y IF_T100_DYN_MSG, y en particular los objetos de excepción, también pueden convertirse en portadores de cualquier mensaje. Esto permite que las excepciones «antiguas» se conviertan en nuevas. La sintaxis completa solo se usa para obtener el contenido de los campos del sistema que se completaron con MENSAJE en los atributos de las clases. A continuación, trato de explicarlo todo con más detalles. Entonces, si también tiene curiosidad por saber cómo evolucionó la mensajería en ABAP, acompáñeme.

Comenzando con Mensajes en ABAP

Mensajes son textos que se crean mediante un mantenimiento de mensajes (transacción SE91) y se almacenan en la tabla del sistema T100. En los programas ABAP, la instrucción MENSAJE es el elemento principal para el uso de mensajes. Es relativamente antiguo e inventado para manejar los errores de los diálogos. En su forma básica, esta sentencia envía un mensaje, especificando un tipo de mensaje y el comportamiento subsiguiente del programa. También es posible determinar cómo se debe mostrar el mensaje en la pantalla definiendo el tipo de pantalla. El tipo de mensaje siempre es sensible al contexto.

Para la forma básica de la declaración MENSAJE, el tipo de mensaje define cómo se muestra el mensaje y determina el flujo de programa posterior. Los tipos de mensajes válidos son A, E, I, S, W y X. Las abreviaturas significan mensaje de terminación (cancelación), mensaje de error, mensaje de información, mensaje de estado, advertencia y mensaje de salida.

Puede agregar Mensajes al programa principalmente de dos maneras. Ya sea codificando el texto del mensaje en el programa o usando la clase de mensaje. Para ser más precisos, lo primero es como usar el formato de mensaje para enviar cualquier tipo de texto en el programa. En este caso, no se requirió ninguna definición antes de codificar el mensaje en el programa.

En caso de usar la clase de mensaje, los mensajes se muestran desde la clase de mensaje que se define usando MESSAGE-ID que se muestra brevemente como id. El número de mensajes varía de 000 a 999 (es decir, 1000 mensajes). Cada mensaje asociado con el número de mensaje y la longitud del mensaje puede tener hasta 80 caracteres.

Originalmente, se podía enviar un mensaje estático usando la sintaxis

…MESSAGE tn(id) …

para especificar un mensaje de la tabla de base de datos T100 donde t y n se utilizan como el tipo de mensaje de un solo carácter y el número de mensaje de tres dígitos directamente uno tras otro. En la forma larga estática, la clase de mensaje se especifica directamente entre paréntesis usando id.

ejemplo yo

Visualización del texto breve del mensaje con el número 001 de la clase de mensaje ZCL_MSG_DEMO como mensaje de información. Primero, creemos una clase de mensaje

Ahora definimos el mensaje 000

escribir el código como

MESSAGE i000(ZCL_MSG_DEMO).

Puede dar la identificación del mensaje de una vez por todas al comienzo del programa. ¡Entonces, la sintaxis puede ser aún más corta!

REPORT ZBLOG MESSAGE-ID ZCL_MSG_DEMO.

MESSAGE i000.

Como se dijo, el comportamiento real del sistema después de enviar un mensaje depende en gran medida del contexto. La versión actual de la documentación de palabras clave ABAP contiene una lista detallada de efectos causados ​​por diferentes tipos de mensajes en diferentes contextos (como procesamiento de diálogo, procesamiento en segundo plano, durante un RFC y durante el procesamiento de solicitudes HTTP).

Por ejemplo, en caso de procesamiento de listas, dicho mensaje terminará el programa.

REPORT ZBLOG MESSAGE-ID ZCL_MSG_DEMO.
START-OF-SELECTION.
 MESSAGE e003.

Además, en el procesamiento de listas, un mensaje de tipo W siempre se convierte a tipo E antes de que tenga lugar un manejo adicional dependiente del contexto. ¡Entonces, tales advertencias también terminan el programa!

Ahora, si lo cambiamos a un procesamiento de diálogoel comportamiento cambia según los módulos de diálogo o los bloques de eventos en los que se envía el mensaje:

REPORT zblog MESSAGE-ID zcl_msg_demo.

PARAMETERS p.

AT SELECTION-SCREEN.

  IF p IS INITIAL.
    MESSAGE e003.
  ENDIF.

El mensaje de error aparecerá hasta que se cumpla la condición.

Así es como los mensajes pretenden controlar los diálogos. Dado que siempre hay otros contextos además del procesamiento de diálogos, SAP tuvo que inventar formas de manejar estos casos. Entonces, se definieron otros tipos de mensajes.

Forma dinámica de mensajes

Más tarde, la forma dinámica de los mensajes se introduce como:

MENSAJE ID mid TIPO mtype NÚMERO num.

La clase de mensaje, el tipo de mensaje y el número de mensaje se especifican como contenido de los objetos de datos mid, mtype y num. mid y mtype esperan objetos de datos similares a caracteres que deben contener la clase de mensaje o el tipo de mensaje en letras mayúsculas. Los tipos de mensajes no válidos generan una excepción que no se puede detectar. num espera un objeto de datos de tipo n y longitud 3. En nuestro caso serían:

DATOS: medio TIPO sy-msgid VALOR ‘ ZCL_MSG_DEMO ‘,
mtype TIPO sy-msgty VALOR ‘I’,
número TIPO sy-msgno VALOR ‘000‘.

La gran diferencia entre la forma dinámica y estática de mensajería es que en forma dinámica puede usar una variable en la declaración del mensaje como

DATA(class) = 'ZCL_MSG_DEMO'  .
MESSAGE id class TYPE 'I' NUMBER '001'.

Pero tal cosa no será posible en la forma estática.

Cuando se utiliza un número de mensaje en el programa, el mensaje correspondiente se recupera de la clase de mensaje y se muestra. Durante este proceso, la información sobre el texto de la excepción se pasa al controlador a través de los campos del sistema. Además, se pueden especificar hasta cuatro operandos. La declaración MESSAGE…WITH utilizada para pasar el texto dinámico o de tiempo de ejecución durante la ejecución del programa. La adición opcional CON se utiliza para proporcionar los marcadores de posición de un mensaje. la sintaxis es

ID DE MENSAJE sy-msgid TIPO sy-msgty NÚMERO sy-msgno

CON sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4 PANTALLA COMO dtype.

dónde

Campos del sistema

Nombre	Significado
sy-msgstr	Contiene la clase de mensaje después de enviar un mensaje.
sy-msgno	Contiene el número de mensaje después de enviar un mensaje.
sy-msgty	Contiene el identificador del tipo de mensaje con el que se envió el mensaje o el texto.
sy-msgv1 a sy-msgv4	Después de enviar un mensaje, contener el contenido de los objetos de datos especificados después de la adición CON en el orden de los objetos. Después de enviar cualquier texto, contenga los primeros 200 caracteres del objeto de datos texto.

La posición de un operando determina qué marcador de posición se reemplaza. Por ejemplo, el contenido formateado de los operandos campo1, …, campo4 se asigna en secuencia a los campos del sistema sy-msgv1 a sy-msgv4. Cuando se utiliza la adición DISPLAY LIKE, se muestra el icono del tipo de mensaje especificado en dtype en lugar del icono asociado. dtype espera objetos de datos similares a caracteres que contengan uno de los valores «A», «E», «I», «S» o «W» en letras mayúsculas. Tenga en cuenta que el uso de esta adición no influye en el comportamiento determinado por el tipo de mensaje, sino solo en el tipo de visualización.

Ejemplo II

En la clase de mensaje definida, creamos otro mensaje con tres marcadores de posición

Ahora puede hacer referencia a este mensaje como

START-OF-SELECTION.

MESSAGE id 'ZCL_MSG_DEMO'  TYPE 'I' NUMBER '001' WITH 'Eat' 'Drink' 'Rest'.

La salida es la esperada:

También se puede escribir de forma abreviada como

MESSAGE i001(ZCL_MSG_DEMO) WITH 'Eat' 'Drink' 'Rest'.

La declaración MENSAJE con la adición EN asigna el texto breve del mensaje al texto del campo de destino. El flujo del programa no se interrumpe y no tiene lugar ningún procesamiento de mensajes.

El texto puede ser una variable similar a un carácter existente o una declaración en línea DATA(var) o FINAL(var), donde se declara una variable de tipo cadena. la sintaxis es

ID DE MENSAJE sy-msgid TIPO sy-msgty NÚMERO sy-msgno

EN DATOS (texto)

CON sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4.

Ejemplo III

A partir del ejemplo anterior, el texto breve de un mensaje se asigna al objeto de datos textom declarado en línea utilizando los campos del sistema correspondientes.

MESSAGE ID 'ZCL_MSG_DEMO' TYPE 'I' NUMBER '000'
          INTO DATA(mtext)
          WITH 'Eat' 'Drink' 'Rest'.
cl_demo_output=>display( mtext ).

Como se dijo, uno puede usar la sintaxis del mensaje para simplemente enviar un texto. La sintaxis para emitir dichos mensajes es la siguiente.

MENSAJE TIPO .

• Mensaje– Mensaje definido por el usuario de 80 caracteres.
• Tipo de mensaje– Especifica el tipo de mensaje.

Ejemplo IV

La codificación del mensaje es simple y de la siguiente manera

* Displaying error Message of type E
MESSAGE 'This is an Error message' TYPE 'E'.

que muestra como

El uso de los mensajes puede variar en los diferentes programas y requisitos funcionales. El programador debe velar por un correcto y buen uso profesional de la mensajería.

Resumen

Aquí, expliqué los conceptos básicos de la mensajería en ABAP. en la próxima publicación, presentaré excepciones (no) basadas en clases y clases de excepciones que incluyen interfaces de mensajes con más detalles. ¡Así que estad atentos!