Cómo habilitar el menú GOS (Generic Object Services) para un usuario SAP determinado

Conozca una de las causas por las que el menú GOS - Generic Object Services - no está habilitado ( no está visible) en transacciones iniciadas por un usuario SAP determinado, y un modo posible de solución.

El menú GOS

El menú GOS (Generic Object Services) es una poderosa herramienta estándar de SAP muy útil para usuarios y desarrolladores que permite el acceso directo a determinadas funciones del sistema.

Entre las funciones ofrecidas por esta herramienta, se cuenta con la posibilidad de monitorear el estado de los Workflows asociados al objeto de negocio que se está visualizando, adjuntarle archivos, notas, URLs, como también es posible enviar emails, arrancar un workflow o chequear los IDocs para el documento.

Leer más...

Tutorial ABAP Objects: Parte 2

En esta Parte 2 del tutorial de ABAP Objects aprenderemos a crear clases, y a definir sus métodos y atributos utilizando la transacción SE80/SE24. Mediante un ejemplo sencillo aprenderemos paso a paso cómo definir todas las componentes necesarias, y "testearlas" luego desde un programa.

En este artículo se mostrará mediante la creación de un programa ejemplo paso a paso,  la implementación de clases, métodos y otras componentes del universo de ABAP Objects. Dado que este tip es el segundo de una serie, si aún so se conocen las generalidades del modelo de objetos y su reflejo en ABAP, es necesaria la lectura previa del tip Tutorial ABAP Objects: Parte 1. Es importante conocer cómo se materializa en ABAP Objects conceptualmente el paradigma de objetos para comprender el desarrollo del ejemplo.

Leer más...

ABAP Objects: Tutorial para implementar el patrón de diseño “decorator”

En este tutorial de ABAP Objects conoceremos conceptualmente los patrones de diseño y aprenderemos cómo implementar, paso a paso, el patrón de diseño "decorator", y probaremos su uso mediante un programa ejemplo en ABAP.

Los patrones de diseño son modelos ("frameworks") de diseño estandarizados, utilizados en la programación orientada a objetos, que buscan ofrecer una solución flexible, prototipada y reusable a ciertos problemas de diseño que ocurren en forma recurrente en un determinado contexto. Cuando se utilizan de manera correcta, los patrones de diseño ayudan a lograr un software reutilizable y mantenible, aumentando la extensibilidad y la portabilidad del sistema. 

Los patrones de diseño tienen que ver fundamentalmente con el diseño y la interacción de los objetos, y son utilizados a través de todo el espectro de entornos OO. El presente artículo analizará la implementación en el mundo de ABAP OO, paso a paso, de un patrón de diseño conocido como "Decorator", a través de un ejemplo. Una vez explicada en forma conceptual la solución y su implementación en ABAP se lo testeará en un programa de prueba.

La utilización de patrones de diseño exige conocer las características particulares del entorno OO que se está utilizando; en otras palabras,  es necesario conocer a qué paradigma dentro del mundo de objetos pertenece ABAP OO, y algunas consideraciones teóricas del patrón de diseño "decorator" en particular. Como se verá en la próxima sección, no todos los lenguajes OO organizan el conocimiento de la misma manera, y hay cuestiones de jerarquía de clases, herencia, y conducta del compilador que afectan el fucnionamiento de los patrones.

En virtud de ello, antes de desarrollar el ejemplo haremos una breve clasificación de los distintos paradigmas en los  lenguajes de programación orientados a objetos. No es el alcance de este tip explicar estos paradigmas en detalle, sino identificar en qué grupo se encuentra ABAP Objects. Si el lector se encuentra familiarizado con los distintos paradigmas de los lenguajes orientados a Objetos, puede omitir la lectura de las dos próximas secciones.

Overview de los diferentes paradigmas de los lenguajes orientados a objetos

Los lenguajes de programación orientados a objetos se pueden clasificar en dos grupos, dependiendo de qué manera organizan el conocimiento:

Por una parte están los lenguajes que organizan el conocimiento de manera jerárquica, mediante clases, y por otra, los que lo hacen a través de prototipos.

El primer caso, por ejemplo, es el de los lenguajes más populares como Java, VB.Net , Smalltalk, C++, Objective-C. Abap OO también pertenece a este grupo. El segundo grupo, que utiliza prototipos, está compuesto por lenguajes menos conocidos como "Self".

Dentro de los lenguajes que conforman el primer grupo se pueden encontrar dos grandes divisiones: lenguajes tipados y no-tipados:

• Los tipados son aquéllos en que el compilador verifica tipos. Cuando se define un atributo o parámetros de entrada o salida del método de una clase en Java por ejemplo, se debe especificar de qué tipo son dichos parámetros.
• En los no-tipados, no existen los tipos. El lenguaje no controla los tipos de variable que declara. Este es el caso de Smalltalk y Objective-C, por ejemplo.

Abap OO pertenece al grupo de los tipados, de hecho, quienes hayan programado en Abap OO y Java, puede apreciar que tienen muchas similitudes y ésto se debe a que ambos pertenecen al mismo paradigma.

Dada la naturaleza de cada grupo, la implementación de un patrón de diseño depende del paradigma al cual pertenezca el lenguaje . En el caso de los tipados, como el compilador verifica tipos, es necesario heredar de una superclase o implementar una interfaz para que dos objetos sean polimórficos. Este es el caso de Abap Objects. En contraste, los lenguajes no tipados, al no tener "tipos",  dicha superclase o interfaz NO es necesaria para que dos objetos sean polimórficos.

Generalidades de los patrones de diseño

Como se dijera en la introducción, un patrón de diseño es un modelo de solución reusable y prototipada a un problema de diseño que se plantea una y otra vez en forma recurrente dentro del mundo de la programación orientada a objetos. La definición de un patrón de diseño incluye:

1) Nombre del patrón: Consiste en una o dos palabras que describen el problema de diseño.

2) El problema: Especifica cuándo aplicar el patrón y explica el contexto.

3) La solución: No describe un diseño concreto ni una implementación en particular, ya que el mismo se puede aplicar en diferentes situaciones. En cambio, el patrón provee una descripción abstracta de un problema de diseño y de qué manera un conjunto de elementos (clases y objetos) lo resuelven.

4) Las consecuencias: Son los resultados que se obtienen al aplicar un patrón. Incluyen su impacto en la flexibilidad, extensibilidad y la portabilidad del sistema.

Objetivo y necesidad del patrón de diseño “Decorator”

Supóngase que se desea agregar a la vista de un texto un botón, un “scroll”, un borde, etc. Imaginemos un contexto donde la vista no puede tener un borde por defecto porque tal vez no se lo necesite o se requiera otro tipo de borde.

Programar distintas vistas que tengan las distintas funciones (vista con scroll; vista con scroll y borde; vista con borde, etc) es una tarea ardua y una solución muy poco mantenible.. Esto ocurre, en primer lugar, porque se debería programar una clase diferente para cada tipo de combinación existente, lo cual es insostenible (con 5 elementos adicionales como scroll, borde, input, text box y table existen 31 combinaciones posibles! ). En segundo lugar, si surge una nueva funcionalidad (un button en la vista por ejemplo), es tanto el nuevo código que se debe programar que resulta inmantenible. Heredar el borde de una clase es otra solución incorrecta, ya que todas las subclases heredarían el borde. Esto es inflexible, porque la elección se llevaría a cabo nuevamente de forma estática.

Si bien en el el presente tutorial se va a explicar el patrón "decorator", existen muchos otros como por ejemplo Singleton, Composite, State, Strategy y Template Method. Cada uno propone una solución general para un problema particular recurrente en diseño.

Enunciado del ejercicio a desarrollar

Se requiere armar el pedido de un café para el bar “El almacén del buen Café”. En este bar un café puede ser de diferente tipo: “Cappuccino”, “Café Latte”, “Americano”, “Ristretto”, etc.

Al café en cuestión se le pueden agregar distintos ingredientes, como por ejemplo: “crema”,”chocolate”, “canela”, “leche”, etc. Es válido agregar el mismo ingrediente dos veces (sería algo como doble crema por ejemplo). Cada tipo de café tiene un precio y cada tipo de ingrediente tiene otro. Se requiere obtener el precio total y la descripción total del pedido.

Por ejemplo si el pedido está formado por el café Cappuccino ($11) y los ingredientes crema ($1) y canela ($0.5). La descripción y precio deberían ser: “Cappuccino, crema, canela” y $12.5, respectivamente. Si el mismo ingrediente se encuentra dos veces, no es necesaria la palabra “doble”. Si el pedido consiste en un Ristretto ($15) con doble crema ($1), alcanza con que la descripción sea: “Ristretto, crema, crema” y el precio: $17.

Análisis de cómo se va a utilizar “decorator”

Supongamos que "El almacén del buen Café" tiene un pedido Cappuccino con los ingredientes crema y canela. Podemos pensar que los ingredientes son decoradores del cappuccino. En primer lugar, el cliente desea un Cappuccino, entonces se crea un objeto cappuccino. Luego el cliente quiere crema, entonces se crea dicho objeto ingrediente (crema) y se hace que “decore” al cappuccino. En términos de programación se va a tener un objeto crema que tiene un objeto cappuccino (composición).

Finalmente el cliente quiere canela, entonces se crea el objeto canela y se lo compone con la crema.

El cómputo de la descripción total se obtendrá de manera recursiva como se puede ver en el siguiente diagrama de secuencia:

El cálculo del precio final del pedido se obtendrá de forma análoga. El método get_price() en lugar de retornar la concatenación de dos “strings”, va a devolver la suma de dos precios.

A continuación se ilustra cuáles son las relaciones de las clases que permiten la solución del enunciado:

Implementación de la solución en Abap OO

Planteado el enunciado del problema a resolver, en los próximos pasos se va a implementar la solución en ABAP.

Para ello se van a crear las tres clases, y se definirán los atributos y los métodos correspondientes. Finalmente, se creará un programa de prueba para testear la solución.

En este Tutorial, se crearán las clases de manera global, mediante la transacción SE80 o SE24. De todas maneras, si el lector lo desea, puede optar por llevar a cabo la creación de las mismas de forma local en un programa.

Los pasos para la implementación de la solución son los siguientes:

1) Se crea la clase Z_CAFE en la transacción SE80 o SE24.

2) Una vez creada la clase Z_CAFE, en la solapa de “Interfaces” se declara la interfaz Z_BEBIDA y se hace doble-click para crearla:

3) Luego dentro de la interfaz Z_BEBIDA, se hace click en la solapa “Atributes” y se declaran los atributos description y price como variables de instancia con los tipos asociados que se muestran a continuación:

Para el tipo asociado a price se eligió un elemento de dato que tiene el siguiente formato:

Elegir algún elemento de dato que tenga características similares. Si tiene las tablas de vuelos (SPFLI, SFLIGHT, SBOOK) puede elegir el elemento de dato S_PRICE.

4) Se hace click en la solapa de “Methods” de la interfaz Z_BEBIDA y se declaran los métodos de instancia:

Se selecciona el método GET_DESCRIPTION y se oprime el botón Parameters. Luego, en la nueva pantalla se define el parámetro de retorno R_DESCRIPTION.

Análogamente se define el parámetro de retorno R_PRICE en el método GET_PRICE. Recuerde definir como tipo asociado el mismo tipo con que definió el atributo. En el caso de este tutorial será ZGF_COFFEE_PRICE.

5) Se activa la interfaz Z_BEBIDA.

6) Se regresa a la clase Z_CAFE. Como ésta implementa la interfaz Z_BEBIDA, debe implementar sus métodos. Se dice que la clase Z_CAFE usa los métodos y los atributos de la interfaz Z_BEBIDA.

7) Se prosigue a escribir la implementación de los métodos. Para ello se hace doble-click en Z_BEBIDA~GET_DESCRIPTION .

Implementación:

METHOD z_bebida~get_description.

r_description = z_bebida~description.

ENDMETHOD.

Luego se escribe la implementación del método GET_PRICE de manera análoga.

Implementación:

METHOD z_bebida~get_price.

r_price = z_bebida~price.

ENDMETHOD.

8) Se agrega el método CONSTRUCTOR en la solapa de “Methods” y se definen los siguientes parámetros:

La implementación del método CONSTRUCTOR es la siguiente:

METHOD constructor.

z_bebida~description = i_description.

z_bebida~price       = i_price.

ENDMETHOD.

9) Se activa la clase Z_CAFE.

10) Se crea la clase Z_INGREDIENTE. En la solapa ”Interfaces” (al igual que como se hizo con la clase Z_CAFE), se declara la interfaz Z_BEBIDA.

11) Dentro de la clase Z_INGREDIENTE, en la solapa de “Methods” se agregan los métodos CONSTRUCTOR y SET_CAFE_COMPUESTO (los métodos GET_DESCRIPTION y GET_PRICE aparecen automáticamente porque la clase implementa la interfaz, al igual que ocurrió con la clase Z_CAFE). En la solapa de atributos se agrega la variable de instancia cafe_compuesto con el tipo asociado Z_BEBIDA.

La solapa de métodos quedará como se ilustra a continuación:

Y la solapa de los atributos, como sigue:

12) Se procede a definir los parámetros de los cuatro métodos e implementarlos.

12.1) Método CONSTRUCTOR: se realiza exactamente igual al método CONSTRUCTOR de la clase Z_CAFE, con los mismos parámetros y la misma implementación (Puede hacer "copy-paste" del código)

12.2) Método SET_CAFE_COMPUESTO:

Parámetros:

Implementación:

METHOD set_cafe_compuesto.

cafe_compuesto = i_cafe_compuesto.

ENDMETHOD.

12.3) Método GET_DESCRIPTION. En ese caso no hay que definir ningún parámetro ya que los mismos surgen de la interfaz Z_BEBIDA.

Implementación:

METHOD z_bebida~get_description.

DATA: desc TYPE string,

desc_final TYPE string.

desc = cafe_compuesto->get_description( ).

CONCATENATE desc z_bebida~description INTO desc_final

SEPARATED BY ', '.

r_description = desc_final.

ENDMETHOD.

12.4) Método GET_PRICE

Implementación:

METHOD z_bebida~get_price.

DATA: parcial_price     TYPE zgf_coffee_price,

final_price          TYPE zgf_coffee_price.

parcial_price = cafe_compuesto->get_price( ).

final_price = parcial_price + z_bebida~price.

r_price = final_price.

ENDMETHOD.

Nota: Recuerde incluir el elemento de dato correspondiente para las variables parcial_price y final_price.

13) Active la clase Z_INGREDIENTE como último paso del desarrollo.

14) El lector puede testear las clases como desee. A continuación se muestra el código de un programa Abap de prueba, en donde se va a realizar la composición de los objetos “a mano” para verificar el funcionamiento. Recuerde nuevamente utilizar el tipo de dato correspondiente para la variable price.

Código ABAP de prueba propuesto:

*&---------------------------------------------------------------------*

*& Report  Z_PRUEBA_PEDIDO

*&

*&---------------------------------------------------------------------*

*&

*&

*&---------------------------------------------------------------------*

REPORT z_prueba_pedido.

DATA: cappuccino     TYPE REF TO z_cafe,

crema         TYPE REF TO z_ingrediente,

canela       TYPE REF TO z_ingrediente,

description          TYPE string,

price         TYPE zgf_coffee_price.

"***Se crean los objetos

CREATE OBJECT cappuccino

EXPORTING

i_description = 'Cappuccino'

i_price       = '11'.

CREATE OBJECT crema

EXPORTING

i_description = 'crema'

i_price       = '1'.

CREATE OBJECT canela

EXPORTING

i_description = 'canela'

i_price       = '0.5'.

"Se Realiza la composicion

crema->set_cafe_compuesto(

EXPORTING

i_cafe_compuesto = cappuccino ).

canela->set_cafe_compuesto(

EXPORTING

i_cafe_compuesto = crema ).

"***Se obtiene la descripcion y el precio

description = canela->z_bebida~get_description( ).

price       = canela->z_bebida~get_price( ).

WRITE: 'Descripcion: ',description,

/,'Precio: ',price.

Salida resultante por pantalla:

Consideraciones adicionales:

1) Notar que en el programa de prueba, la composición se realizó “a mano” para testear las tres clases. Se recomienda crear una clase "armadora" llamada “Z_ARMADOR_CAFE” que encapsule la composición de los objetos. La forma de implementar la clase queda librada al lector.

2) Notar también que para poder implementar el patrón se requirió que los objetos de la clase CAFE e INGREDIENTE sean polimórficos. En los lenguajes tipados, se necesita heredar de una superclase o implementar una interfaz para que dos objetos sean polimórficos. Es por eso que se usó la interfaz BEBIDA. Se podría haber utilizado una clase abstracta, pero se optó por usar una interfaz ya que no se encuentra una superclase apropiada que tenga como subclases a CAFE e INGREDIENTE. Igualmente si el lector lo desea, puede probar la alternativa de usar una clase abstracta.

3) Observar que no se creó una clase para cada ingrediente y que las mismas heredan de una superclase INGREDIENTE. Se creó una única clase porque todos los ingredientes tienen la misma forma de calcular su costo y su descripción (mismo comportamiento). Suponga ahora que el precio de la leche está dado por 50ml y que el cliente puede decidir cuántos ml de leche quiere. En este caso el precio de la leche va a depender de un atributo adicional que es la cantidad solicitada. Por lo tanto en este caso tiene sentido crear una clase abstracta INGREDIENTE con subclases LECHE y CANELA por ejemplo.

4) Analizar cómo cambia la implementación del patrón en los lenguajes no-tipados como Smalltalk. En ese caso no se necesitaría de la interfaz o clase abstracta BEBIDA, ya que en dichos lenguajes no se requiere de herencia para que dos objetos sean polimórficos. Es por esta razón que se explicó a qué paradigma pertenece Abap OO.

5) Observar que para invocar los métodos get_price() y get_description() se utilizó la forma un_objeto->nombre_interfaz~un_metodo( ). De esta manera queda expuesto el uso de la interfaz, lo cual no es conveniente. Para lograr una mejor encapsulación se recomienda el uso de “alias”. Esto no es más que un alias para poder llamar al método con otro nombre. De esta manera, se puede invocar al método mediante un_objeto->un_metodo( ) sin exponer el uso de la interfaz.

Especialista ABAP

Copyright 2012 - Teknoda S.A.

Tutorial ABAP Objects: Parte 1

Conozca el universo de la programación orientada a objetos en SAP implementada con ABAP Objects. En este “tip”, el primero de la serie de Tutoriales de ABAP Objects, veremos conceptualmente cómo se implementa el paradigma de objetos en el mundo SAP. En los próximos artículos se tratarán en detalle ejemplos de programación paso a paso, y otras características del entorno.

La programación orientada a objetos (POO) es una filosofía de diseño y desarrollo de software donde el modelo informático es un reflejo de las entidades del mundo real. A diferencia de los lenguajes tradicionales, donde existen procedimientos por un lado y datos por el otro, la POO permite a los programadores representar cada entidad del problema como un objeto “encapsulado” que contiene tanto sus datos y cómo los “comportamientos” gestionan sobre ellos.

Leer más...

"Application Logging" en ABAP: Cómo mejorar su código implementando registro de mensajes

Aprenda en un tutorial paso a paso cómo utilizar las herramientas de SAP para implementar Application Logging (Registro de Aplicaciones). Mejore la calidad de su código y mejore su mantenimiento a través del registro de excepciones, mensajes y errores.

Un sistema de registro, (“logging”) bien diseñado es una necesidad básica para la salud de cualquier sistema de misión crítica. La actividad de logging consiste en el registro de la actividad de mensajes del sistema y/o sus aplicaciones, lo que salva muchas horas valiosas al equipo de soporte o desarrolladores a la hora de monitorear errores, reconstruir eventos, etc. 

En el caso de SAP, como en la mayoría de los sistemas, existe un SYSTEM LOG que registra los eventos a nivel del sistema operativo. Además, SAP provee las herramientas para implementar un APPLICATION LOG para todos los programas ABAP desarrollados. A través de determinadas transacciones, tablas y módulos de función, SAP proporciona una infraestructura para la recepción de mensajes y excepciones en un registro, el ahorro, la lectura y  borrado de registros en la base de datos y su visualización.

El archivo de APPLICATION LOG contiene sucesos registrados por las aplicaciones, y, a diferencia del system log, los eventos que se escriben en el Application Log están determinados por los desarrolladores.

Usando esta funcionalidad, se establece una forma estandarizada de almacenar mensajes de error, permitiendo un manejo más simple de mismos y mejorando la calidad del código.

La funcionalidad de registro de aplicaciones existe desde la versión 3.0, pero fue notablemente mejorada a partir de la versión 4.6. Si bien las funciones de la versión 3.0 están aún soportadas, trabajaremos en este tip con las mejoras de la 4.6.

Estructura de un Application Log

• En términos generales, se define como "log" a un conjunto de mensajes. Un log usualmente también contienen una cabecera con información descriptiva: número de log, creador, hora de creación, etc

• El Application Log es una estructura de tablas compuesta por varias tablas. La gestión sobre dichas tablas se realiza utilizando módulos de función estándar provistos por SAP.

• Los datos de logging se recolectan inicialmente en la memoria local, y luego pueden ser grabados en la base de datos. Esto permite acelerar el proceso al reducir la cantidad de accesos a la base de datos.

• Cada transacción puede generar varios logs.

• La estructura del application log es:

- CABECERA DE LOG. Número de log, Usuario, Fecha de generación, Programa o Transacción y Clase de mensaje.

-  MENSAJES DE LOG.

Transacciones utilizadas para gestionar Application Logging.

Hay diferentes transacciones involucradas en la gestión de un application log :

SLG0 New Entry: Transacción utilizada para CREAR y DEFINIR las entradas para sus propias aplicaciones en el Application Log. (Desarrollador)

SLG1 Analyze Application Log: Transacción para ANALIZAR el registro de aplicación. (Usuario principal)

SLG2 Delete Expired Logs: Transacción para ELIMINAR registros caducos. (Administrador)

Módulos de Función para Application Logging

Como se dijo anteriormente, la funcionalidad de registro de aplicaciones existe desde la versión 3.0, pero fue notablemente mejorada a partir de la versión 4.6. Todas los módulos de función tipo “APPL_LOG” existen desde la versión 3.0 (ver tabla más abajo).

A partir de la 4.6 aparecen los módulos de función que comienzan con el prefijo SBAL, mucho más completos y mejor documentados que las antiguas funciones APPL_LOG.

Los principales módulos de función estándar son:

• BAL_LOG_CREATE     (Abrir un Application Log )
• BAL_LOG_MSG_ADD   (Generar una entrada con un mensaje en el Application Log )
• BAL_LOG_MSG_ADD_FREE_TEXT   (Generar una entrada con exto libre en el Application Log )
• BAL_DSP_LOG_DISPLAY (Mostrar el Application Log )

Exsite además una extensa lista de funciones para gestionar en detalle sobre la base de datos del Application Log, recolectar mensajes, grabar, eliminar, visualizar, etc.

Puede correr SBAL_DOCUMENTATION para ver la documentación completa.

LOS MÓDULOS DE LA VERSIÓN 3.0 AÚN PUEDEN UTILIZARSE Y ESTOS INVOCARAN A SUS EQUIVALENTES DE LA VERSION 4.6

También es posible implementar sus propios módulos de función para  su  Application Log , pero esto no se abarcará en este tip.

Funciones utilizadas para gestionar Application Logs (a partir de 4.6)

A continuación veremos paso a paso cómo es la creación de Application Log  y su posterior visualización.

Estructura de los módulos de Función más utilizados

BAL_LOG_MSG_ADD y BAL_LOG_MSG_ADD_FREE_TEXT son  módulos de función estándar de SAP. A continuación se presentan los detalles de estos FM. Toda esta información y más se pueden ver si se introduce el nombre del módulo de función BAL_LOG_MSG_ADD en la correspondiente transacción SAP como SE37 SE80 .

Estructura  BAL_LOG_MSG_ADD

CALL FUNCTION 'BAL_LOG_MSG_ADD'   "Application Log: Log: Message: Add

EXPORTING

* i_log_handle =                          " balloghndl        Log handle

i_s_msg =                                   " bal_s_msg       Notification data

IMPORTING

e_s_msg_handle =                             " balmsghndl     Message handle

e_msg_was_logged =                        " boolean          Message collected

e_msg_was_displayed =                   " boolean          Message output

EXCEPTIONS

LOG_NOT_FOUND = 1                      "                         Log not found

MSG_INCONSISTENT = 2                   "                        Message inconsistent

LOG_IS_FULL = 3                              "                        Message number 999999 reached. Log is full

.          " BAL_LOG_MSG_ADD

Estructura BAL_LOG_MSG_ADD_FREE_TEXT

CALL FUNCTION 'BAL_LOG_MSG_ADD_FREE_TEXT'                        "Application Log: Log: Message: Insert as free text

EXPORTING

* i_log_handle =                                     " balloghndl      Log handle

i_msgty =                                               " symsgty        Message type (A, E, W, I, S)

* i_probclass = '4'                                  " balprobcl       Problem class (1, 2, 3, 4)

i_text =                                                   " c                   Message data

* i_s_context =                                      " bal_s_cont     Context information for free text message

* i_s_params =                                      " bal_s_parm    Parameter set for free text message

IMPORTING

e_s_msg_handle =                                " balmsghndl    Message handle

e_msg_was_logged =                          " boolean          Message collected

e_msg_was_displayed =                     " boolean          Message output

EXCEPTIONS

LOG_NOT_FOUND = 1                         " Log not found

MSG_INCONSISTENT = 2                     " Message inconsistent

LOG_IS_FULL = 3                                " Message number 999999 reached. Log is full

.       " BAL_LOG_MSG_ADD_FREE_TEXT

Creación de un Application Log Paso a Paso

Para la creación de los objetos de un Application Log se deben seguir los siguientes pasos:

PASO 1: Ir a la transacción SLG0 y crear el objeto, completar su descripción. Luego salvarlo y asignarlo a un paquete y a una OT . Luego para crear el subobjeto, seleccionar el objeto creado ZTEST, seleccionar NEW ENTRIES y completar el nombre y la descripción del subobjeto y luego Salvar .

PASO 2: Ir a la transacción SE80 y crear un programa con TOP INCLUDE, completar el titulo , tipo , status y aplicación, salvar y asignar paquete .

PASO 3: Copiar el siguiente código en el programa ZLOGGING, salvar y activar, y posteriormente ejecutar. De esta forma se podrá visualizar el aplication log implementado.

La finalidad del código siguiente es el de generar el application log, la implementación de  los propios mensajes en éste, y la visualización del log con los mensajes implementados.

---------------------------PARTE PRINCIPAL DEL PROGRAMA ---------------------------
INCLUDE ZLOGGINGTOP.
INCLUDE ZLOGGINGFORMS.
START-OF-SELECTION.
PERFORM LOG_CREATE.
PERFORM ADD_MSG_FREE_TEXT.
PERFORM ADD_MSG.
PERFORM LOG_DISPLAY.

---------------------------- PARTE DEL TOP INCLUDE --------------------------------
* DEFINICION DE TIPOS Y VALRIABLES A UTILIZAR EN EL LOG

TYPES : BALSMG TYPE STANDARD TABLE OF  BAL_S_MSG.

DATA:  LS_LOG TYPE BAL_S_LOG,

L_LOGHAND TYPE BALLOGHNDL,

L_MSG TYPE BAL_S_MSG,

B_LOG TYPE BOOLEAN,

B_DISP TYPE BOOLEAN,

LT_MSG TYPE BALSMG,

WA_LT_MSG TYPE BAL_S_MSG.

* ASIGNACION A LA ESTRUCTURA LS_LOG DE LOS SIG.ATRIBUTOS :
* ASIGNACION DEL  OBJETO Y SUBOBJETO

LS_LOG-OBJECT = 'ZTEST'.

LS_LOG-SUBOBJECT = 'ZTESTSUB'.

* ASIGNACION  DE PROGRAMA Y ID EXTERNO

LS_LOG-ALPROG ='ZLOGGING'.

LS_LOG-EXTNUMBER =' 001 APPLICATION LOG'.

* DEFINICION DE VARIABLES PARA MENSAJE DE  TEXTO LIBRE

DATA:

LL_MSG(60) TYPE C,

G_LOG TYPE BALLOGHNDL,

P_FACPRO(15) TYPE C  VALUE 'INFORMATIVO',

CONTRATO_BASE(20) TYPE C VALUE 'MENSAJE CREADO'.

------------PARTE DEL FORMS INCLUDE ----------------------------------------

FORM LOG_CREATE.

* FUNCIÓN PARA LA CREACIÓN DEL LOG

CALL FUNCTION 'BAL_LOG_CREATE'

EXPORTING

I_S_LOG = LS_LOG

IMPORTING

E_LOG_HANDLE = L_LOGHAND

EXCEPTIONS

LOG_HEADER_INCONSISTENT = 1

OTHERS = 2.

ENDFORM.

FORM ADD_MSG.

* GENERACION DE LOS MENSAJES PERSONALIZADOS
* MENSAJE DE INFORMACION

L_MSG-MSGTY = 'I'.
L_MSG-MSGID = '00'.
L_MSG-MSGNO = '398'.
L_MSG-MSGV1 = 'TESTING 1234'.
APPEND L_MSG TO LT_MSG.

* MENSAJE DE ADVERTENCIA

L_MSG-MSGTY = 'W'.
L_MSG-MSGID = '00'.
L_MSG-MSGNO = '398'.
L_MSG-MSGV1 = 'WARNING TESTING 1234'.
APPEND L_MSG TO LT_MSG.

* MENSAJE DE ERROR

L_MSG-MSGTY = 'E'.
L_MSG-MSGID = '00'.
L_MSG-MSGNO = '398'.
L_MSG-MSGV1 = 'ERROR TESTING 1234'.
APPEND L_MSG TO LT_MSG.

* LOOPEAR LA TABLA PARA AGREGAR LOS MENSAJES CREADOS Y UTILIZAR LA
LOOP AT LT_MSG INTO WA_LT_MSG.

* FUNCION PARA ADICIONAR LOS MENSAJES EN EL LOG .

CALL FUNCTION 'BAL_LOG_MSG_ADD'

EXPORTING

I_LOG_HANDLE = L_LOGHAND     Log handle

I_S_MSG = WA_LT_MSG              Notification data

IMPORTING

E_MSG_WAS_LOGGED = B_LOG       Message handle

E_MSG_WAS_DISPLAYED = B_DISP    Message output

EXCEPTIONS

LOG_NOT_FOUND = 1     Log not found

MSG_INCONSISTENT = 2  Message inconsistent

LOG_IS_FULL = 3       Message number 999999 reached. Log is full

OTHERS = 4.

ENDLOOP.

ENDFORM.

FORM ADD_MSG_FREE_TEXT.

CONCATENATE 'texto :' p_facpro 'para un ' contrato_base

INTO ll_msg SEPARATED BY space.

* FUNCION PARA ADICIONAR LOS MENSAJES EN EL LOG CON TEXTO LIBRE.

CALL FUNCTION 'BAL_LOG_MSG_ADD_FREE_TEXT'

EXPORTING

i_log_handle     = g_log

i_msgty          = 'I'            "tipo de error

i_text           = ll_msg

EXCEPTIONS

log_not_found    = 1

msg_inconsistent = 2

log_is_full      = 3

OTHERS           = 4.

IF sy-subrc <> 0.

MESSAGE ID sy-msgid TYPE sy-msgty NUMBER sy-msgno

WITH sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4.

ENDIF.

ENDFORM.

FORM LOG_DISPLAY.

* FUNCION PARA MOSTRAR EL LOG IMPLEMENTADO

CALL FUNCTION 'BAL_DSP_LOG_DISPLAY'.

ENDFORM.

Visualización del Application Log

Para tener en cuenta:

• Los Application Log tienen carácter de temporarios, y están para monitorear el curso de una aplicación. No es el objetivo actuar como registros definitivos de datos críticos. Los datos que deben ser almacenados por largo tiempo por razones de seguridad deben almacenarse con los documentos de cambio.
• Se se utiliza application logging en escenarios complejos, por ejemplo, muchísimos usuarios concurrentes sobre la aplicación (Ej. venta de pasajes distribuida), deberá contemplarse los principios de programación fundamentales, usando colas de mensajes, save, commit, etc.
• Pueden encontrarse respuestas a varias inquietudes en las notas de OSS, utilizando como criterio de búsqueda "BC-SRV-BAL". También pueden encontrarse programas ejemplo de application logging pulsando F4 sobre “SBAL_DEMO_*” en la transacción SE38.

Especialista ABAP

Copyright 2012 - Teknoda S.A.

Cómo crear y testear secuencias de funciones en ABAP con el Function Builder

Aprenda con un ejemplo paso a paso cómo crear y testear secuencias de funciones en ABAP para que operen como una unidad, a través del Funtion Module Test Sequence, parte del Function Builder.

Cuando se está desarrollando en ABAP, en determinadas situaciones resulta necesario ejecutar dos o más funciones en secuencia. La idea en estos casos es que las funciones secuenciadas operen como una unidad, de manera que el output de la precendente sirva de input a la siguiente, y se garantice la ejecución conjunta de las mismas para llegar al resultado deseado. 

Entre inumerables ejemplos, un caso clásico son las actualizaciones a las bases de datos. Por ejemplo, si se utiliza una BAPI para dar un alta en una base de datos NO se verá el registro agregado hasta que otra BAPI que ejecute un COMMIT. Si la aplicación requiere la disponibilidad inmediata del registro puede asegurarse la secuencia de BAPIS utilizando una secuencia de funciones que incluya primero el alta, e inmediatamente, el COMMIT.

La transacción SE37 (Function Builder) ofrece la herramienta “Test Sequence” que permite armar y “Testear” secuencias de funciones con este fin.

Explicamos en este tip cómo utilizar Function Module  Test Sequence con un ejemplo paso a paso.

Ejemplo de Function Module Test Sequence

Se ejemplificará ese escenario en este tip mediante de BAPIS, utilizando un caso bastante emblemático, que son los cambios a las bases de datos.  La idea es dar de alta un registro a una base de datos y hacerlo inmediatamente disponible a la aplicación.

Para ello, se requerirán dos BAPIs en secuencia:

• BAPI_FLCUST_CREATEFROMDATA (que dará de alta un cliente)
• BAPI_TRANSACTION_COMMIT.

En este caso, si se ejecuta sólo BAPI_FLCUST_CREATEFROMDATA, los cambios realizados por la misma, no serían inmediatamente visibles a la aplicación en curso. Las altas a una base de datos NO se reflejan en forma inmediata, sino recién cuando se halla ejecutado el COMMIT de dicha operación. Por lo tanto, para que el registro se haga visible, se requiere la ejecución exitosa de toda la secuencia de funciones, como si fueran una unidad.

Pasos para testear la ejecución de dos BAPIS de forma secuencial:

1) Acceder a la transacción SE37. Una vez allí, seleccionar de la barra de menú de SAP, la opción Function Module, luego “Test” y finalmente “Test Sequences”.

2) En la ventana de selección se  ingresan las dos BAPIS a secuenciar, en este caso BAPI_FLCUST_CREATEFROMDATA y BAPI_TRANSACTION_COMMIT, obviamente en el orden deseado.

3) Al aceptar con Execute, el sistema abrirá la Initial Screen para esta función.

Debemos a esta altura ingresar los parámetros para la función, que en este caso serán los campos necesarios para el alta de un cliente. Desde la Initial Screen, utilizando el ícono "Details View Edit" se abre la interfaz del "Structure Editor", donde se procederá a completar los datos.

En la pantalla de Structure Editor es conveniente presionar las teclas SHIFT + F7 para tener una mejor visión (vertical!) de los datos y que el ingreso sea más sencillo, como se muestra en la figura anterior.

Para este ejemplo sólo se completan los datos correspondientes a CUSTNAME (Nombre del cliente), STREET (Calle), COUNTR (País) y CUSTTYPE (Tipo de cliente) (Sólo valor B o P).

Finalizada la entrada de datos con el icono de “Aceptar”, se desplegará el registro con los datos de testeo cargados, tal como vemos a continuación. Desde acá, se debe regresar a la Initial Screen de la función, utlizando el botón señalado en la misma figura.

4) Luego desde la Inicial Screen, se procede a su ejecución  a través de la tecla F8 (o el ícono correspodiente)

Completada la ejecución, el sistema volverá a la Initial Screen. Sin embargo, se observará en la zona de tablas, la referencia a una nueva entrada con un mensaje. El número ("1" en este caso) informa cuántos mensajes o advertencias se han generado como resultado de la ejecución. Para acceder a la interfaz con el resultado de la ejecución, se deberá hacer click sobre esta referencia (ver figura siguiente).

Allí, se puede verificar que la primera BAPI ejecutada en la secuencia haya operado correctamente, es decir, que el registro haya sido dado de alta. Aparecerá el mensaje correspondiente indicando que el cliente (JUAN LOPEZ) ha sido creado, como se muestra en la figura:

5) Para continuar el procedimiento debemos regresar hasta la Initial Screen de la segunda BAPI (BAPI_TRANSACTION_COMMIT). Presionar el botón "Atrás"   dos veces para continuar con el procedimiento.

6) Se observa  en la Inicial Screen para esta BAPI , que no hay parámetros para ingresar, ya que el resultado de la ejecución de la primera BAPI está sirviendo como input para esta otra. En la posición del cursor colocar una “x” y luego presionar F8 para ejecutar:

7) Al igual que en el caso anterior, el sistema nos llevará a la pantalla de resultados una vez completada.

De esta manera se ha creado una nueva entrada para el cliente ingresado recientemente en la tabla SCUSTOM utilizando la BAPI BAPI_FLCUST_CREATEFROMDATA para la creación del cliente y BAPI_TRANSACTION_COMMIT para que sea grabada en la Base de Datos.

Para tener en cuenta …

• Si se desea comprobar que luego de la ejecución de las dos BAPIs mencionadas en secuencia, se ha creado efectivamente el nuevo registro en la tabla SCUSTOM, chequear por medio de la transacción SE11 dicha tabla.
• Si se ejecutara sólamente la BAPI BAPI_FLCUST_CREATEFROMDATA (sin realizar la acción de Commit), al chequear la tabla SCUSTOM, se comprobará que el registro cargado por la primera BAPI, no fue grabado en la base de datos.

Especialista ABAP

Especialista ABAP

Copyright 2012 - Teknoda S.A.

Sap HANA en "pastillas": Parte 3

En la tercera entrega de esta serie de artículos continuamos tratando de profundizar el entendimiento de SAP HANA, su materialización, y su proyección futura. Mediante preguntas y respuestas abordaremos distintos aspectos de esta tecnología, siempre con un enfoque objetivo y conceptual.

¿Por qué SAP HANA despierta tanto interés? ¿Es SAP HANA una solución, una plataforma, una tecnología, un software? ¿Cómo se materializa en términos de producto? ¿Cómo se relacionan SAP HANA "appliance" y sus componentes de sofware? ¿Quién es el cliente principal para SAP HANA? ¿Qué significa el tratamiento columnar de bases de datos? ¿Qué relación hay entre SAP HANA y BW? ¿Cómo afectará SAP HANA a la plataforma del SAP ERP en el mediano y largo plazo? ¿Qué destrezas se requerirán para sacar provecho de esta tecnología? ¿Significa SAP HANA que SAP es un nuevo competidor en el mercado de base de datos, a la par de Oracle y otros? ¿Cómo puedo empezar a acercarme a esta tecnología? ¿Qué es SAP HANA CLOUD platform?

Leer más...

Cómo obtener la edición GRATUITA del libro SAP HANA Essentials

Aproveche la campaña de SAP para difundir HANA, accediendo a la edición promocional SIN CARGO de su libro "estrella": "SAP HANA Essentials". Le contamos como obtener un "voucher code" y los links para descargarlo.

SAP HANA Essentials eBook

Format: EPUB & Kindle
Author: Jeffrey Word
Publication Date: May 2012
Edition: Spring 2012
Pricing: EUR 59.99

En los últimos meses, SAP ha estado trabajando febrilmente y contra reloj en un libro que pueda ofrecer a lectores, tanto del área técnica como de negocios, una visión amplia y un entendimiento a fondo  de la arquitectura, herramientas y capacidades de SAP HANA. El libro SAP HANA Essentials es el resultado de este trabajo, y la edición completa del mismo, está disponible a un precio de 59 Euros.

Leer más...

Smartforms Vs. SAPScript: Resumen de las principales diferencias

Conozca a primera vista las principales diferencias entre SmartForms y SAPScript para el tratamiento de formularios en ABAP.

Tutorial ABAP paso a paso: Cómo crear un Smartform

Conozca cómo crear un Smartform paso a paso en base a un Layout definido  y a un programa impresor creado previamente.

En el tip “Cómo crear el programa impresor para la ejecución de un Smartform en SAP” publicado anteriormente en Teknodatips, fue detallado el procedimiento para crear el programa impresor necesario para ejecutar el smartform que va a ser creado en este tip. 

IMPORTANTE: es necesaria la lectura del tip mencionado para un mejor entendimiento del tip presente en donde se detallará paso a paso la creación del Smartform, que será luego ejecutado por el programa impresor creado en el tip anterior mencionado.

Pasos para crear un Smartform

a) Pasos para configurar la lógica del Smartform

1) Acceder a la transacción: SMARTFORMS, escribir el nombre del formulario (Ej. ZPRUEBA) que se va a crear, y luego presionar el botón Create para empezar a definir las características del Smartform.

2) Se llega a la pantalla principal de la transacción SMARTFORMS. Se observa que la pantalla está dividida en dos “paneles”: sobre la izquierda se presenta una estructura de árbol y sobre la derecha se posibilita realizar modificaciones y visualizar opciones según lo seleccionado sobre el panel izquierdo. Es conveniente en este punto Guardar el formulario para asignarlo a un Paquete y asociarlo ya a una Orden de Transporte:

3) En este paso se definirán los datos de entrada. Para ello seleccionar sobre el panel de la izquierda, Form Interface y se observará (sobre el panel derecho) que está compuesto por las solapas: Import, Export, Tables y Exceptions.

4) Sólo se utilizarán las solapas 1 y 3. En el apartado Import (1) se detallarán aquellos parámetros de entrada que tendrá el formulario, a excepción de las tablas que irán en Tables (3).

Los parámetros de entrada se corresponderán con los parámetros de salida definidos en el programa impresor: FLDATE (DATE1), CARRIER(CARRIER1) y CONNECTION (CONNECTION1) con su correspondiente tipo de dato.

En Export (2) y en Exceptions (4) no será necesario hacer modificaciones.

5) En Tables (3) habrá que definir como parámetro de entrada una tabla interna que se corresponde con la estructura definida como parámetro de salida en el programa impresor (GS_SBOOK), como se muestra en la figura siguiente:

6) Seleccionar sobre la izquierda el item Global Definitions que permitirá especificar cuáles serán las estructuras que utilizará el Smartform para almacenar la información que será pasada como parámetro.

Para este ejemplo en particular, sólo será necesario añadir bajo la solapa Global Data una “Work Area” del tipo de datos de la tabla interna pasada como parámetro, para luego poder recorrerla:

7) Sobre el panel de la izquierda seleccionar Pages and Windows, que definirá el aspecto visual del Smartform y cómo se muestran los datos en él. %PAGE1 New Page corresponde al nombre de la página del formulario (este nombre aparece por defecto, pero puede ser cambiado). Este ejemplo tendrá solo una página (la cantidad va a depender del comportamiento de cada página):

b) Pasos para definir el diseño del Smartform

En los pasos anteriores se definió la lógica que maneja el Smartform, los próximos pasos servirán para entender y definir el diseño del Smartform. Para ello será necesario crear diferentes elementos que conformarán el diseño Ventanas (Windows), textos (Texts) y Plantillas (Templates).

Tener en cuenta que el Layout a definir se corresponderá con el ya especificado y utilizado en el programa impresor definido en el tip anterior "Cómo crear el programa impresor para la ejecución de un Smartform en SAP, representado como sigue:

NOTA: Considerar que una Window o Ventana está relacionada con cada recuadro en color amarillo definido dentro del layout.

Será necesario en este paso para empezar a definir el diseño, lograr una estructura jerárquica sobre el panel de la izquierda, similar a la que se muestra a continuación donde se utilizan los nombres de esos elementos asignados por default. (Considerar la posibilidad de cambiarlos por nombres más representantivos en cada caso):

Para lograr obtener los elementos que conforman la estructura del diseño del Smartform, como se muestra en la imagen anterior, será necesario:

1) Para Crear una Window hacer click derecho sobre la página (por defecto %PAGE1 New Page), luego Create y finalmente seleccionar Window.

2) Aparecerá la siguiente pantalla, donde se definirán los atributos de esa Window:

NOTA: tener en cuenta el uso de la herramienta Form Painter para asistir al diseño del “Layout” de las ventanas:

3) Luego para Crear un Texto dentro de la Window (que será un título o datos de un campo), hacer click derecho sobre la Window corriente (por defecto %WINDOW1 New Window1) y luego seleccionar Text.

Así se verá un texto recién creado siguiendo el paso anterior, donde el nombre fue cambiado a %TEXT7 New Text 7:

4) En este punto será necesario indicarle al Smartform qué contenido tendrá cada texto definido:

Como ejemplo, se asignará el título Flights al texto %TEXT7 New Text7.

Se hará de la siguiente manera:

5) Seleccionar sobre el panel izquierdo, %TEXT7 New Text7 (el texto creado anteriormente) y sobre la pantalla que aparece en el panel de la derecha, hacer click en sobre el ícono remarcado en rojo:

6) Al presionar el ícono anterior indicado, aparece la pantalla para ingresar el contenido del texto, en este caso para el título Flights, se escribe como se muestra en la siguiente imagen:

Una vez escrito el texto, habrá que volver hacia atrás

Tener en cuenta que si el contenido del texto es un titulo, se necesita ingresar sólo el texto que se desee (como en el caso de Flights), en cambio si el contenido del texto es un campo (es una variable, estructura de datos, work area, tabla interna, etc), se lo deberá ingresar entre signos ampersand (&).

Volviendo a referenciar el layout del ejemplo, para definir la segunda ventana:

es necesario ingresar más de un campo, por lo tanto es conveniente introducir el concepto de “Template” que básicamente permite ingresar campos o títulos en filas y/o columnas dentro de una misma ventana (en forma de matriz o grilla).

7) Por lo tanto, se deberá crear un Template . Para ello, hacer click derecho sobre la ventana (%WINDOW2 New Window2), luego sobre Create y finalmente seleccionar Template:

Como resultado aparecerá la pantalla con el Template creado:

Con todos los pasos anteriormente especificados, se debería obtener una estructura jerárquica similar a la siguiente (algunos nombres pueden variar):

Recordar siempre guardar los cambios y activar el Smartform

Se ejemplificará sólo cómo configurar el Template de la ventana que contiene Carrier y Connection Id y sus respectivos campos, es decir cuatro textos en total, dos corresponden a los titulos y los otros dos a los campos.

NOTA: El Template contenido en la ventana 3 del layout (Date como título y Field 3 como campo), NO será ejemplificado en este caso.

8) La ventana que contendrá al template ejemplificado se configurará de la siguiente manera:

Hacer doble click sobre la Ventana a modificar, y luego seleccionar “Output Options”

9) Considerar los siguientes datos, para el tamaño y la ubicación de la ventana:

10) Para configurar el template, hacer doble click sobre el template a modificar y seleccionar el icono (lápiz) para dibujar dos lineas (una vertical y una horizontal), como se muestra en la siguiente figura:

Luego se hará click en en el botón details: y aparecerá la pantalla siguiente, y luego completar de acuerdo a los valores presentados en la siguiente pantalla:

11) En este paso deberá crearse un texto por cada título o campo que deba ser ingresado al template (de acuerdo con la jerarquía definida en la figura), de la misma manera que fue creado para una Window, además de ingresar el título o el mapeo para el campo correspondiente.

Se hará click en cada uno de los textos que se desprenden del template:

Y a cada uno de ellos se le asignará una fila y una columna según corresponda:

En el ejemplo, este texto va en la Fila 2 (Line 2) y en la Columna 1(Column 1).

• Para las ventanas restantes que contengan templates, el proceso será el mismo que el detallado en los pasos anteriores.

12) Finalmente,  se detallará cómo trabajar con un tipo de ventana especial llamada MAIN (definida en el layout de color gris), que contendrá a la tabla interna pasada como parámetro.  Una vez definidos los pasos que se detallarán a continuación , la estructura jerárquica de la ventana  MAIN deberá quedar de la siguiente manera:

Definición de la ventana MAIN

Para lograr el diseño de esa estructura de MAIN, será necesario seguir los siguientes pasos:

1) MAIN siempre aparece por defecto en la estructura al crear el Smartform, y se visualizará de la siguiente manera:

2) Dentro de la ventana  MAIN será necesario crear una tabla. Para ello: Botón derecho sobre MAIN, luego Create y finalmente seleccionar Table:

3) Luego, aparecerá la pantalla siguiente en donde, para el ejemplo, se deberá cambiar el nombre de la tabla (campo Tabla),  a GS_BOOK y presionar Enter.:

4) Posteriormente, seleccionar la solapa “Data”:

5) En Data se deberán colocar: la tabla interna recibida como parámetro (GS_BOOK) y luego de INTO, escribir la “Work Area” que fue definida en Global Definitions (AUX_GS_SBOOK) como se muestra en la siguiente imagen:

6) Luego, al seleccionar la solapa TABLE, aparecerá en la parte inferior de la pantalla un recuadro, que por defecto contiene  %LTYPE1. Hacer click sobre el rectángulo (pasará a color negro) y luego presionar el botón "Details":

7) Cambiar %LTYPE por LINEA que indica el ancho de la fila (siempre recordar en cada paso es necesario grabar y activar para comprobar que no hay errores)

8) Luego click derecho sobre Header bajo GS_BOOK, en la estructura jerárquica de la izquierda, seleccionar Create y finalmente Table Line:

9) Posteriormente, al desplegar Header aparecerá la “Table Line” recientemente creada. Cambiar el nombre por HEADER y en Line Type seleccionar LINEA:

Se deberán repetir los pasos detallados anteriormente tanto para Main Area como para Footer, también visualizados sobre la estructura jerárquica (sólo variará el nombre de cada uno)

Se desplegarán tanto Header, Main Area como Footer y de cada uno de ellos se desprenderán sus celdas (llamadas Cell) que son creadas automáticamente:

10) Dentro de cada “CELL” se colocarán los textos correspondientes (realizar el mismo procedimiento ya explicado anteriormente para las Ventanas). A modo de ejemplo, en la CELL correspondiente al Header, se colocará un texto llamado %TEXT 9 New Text 9 (Botón derecho → Create → Text )

11) En este caso, el texto agregado llamado %TEXT 9 New Text 9, llevará los títulos de la tabla que se mostraron anteriormente en el layout. La forma de ingresar información dentro del texto es igual a la detallada anteriormente, salvo que en este caso si fuese necesario dejar espacios entre campos y textos, se hará utilizando doble comas ( ,, ). Tener en cuenta que dos comas corresponden a un tabulador:

La imagen siguiente muestra la estructura con los textos que fueron agregados a cada componente (Header, Main Area, Footer)

12) En la estructura jerárquica, Main Area contendrá los campos que se corresponden con los campos de la tabla en el layout. Tener en cuenta que como son campos tiene que ir entre signos "&" (ampersand).

13) Finalmente, la sección de Footer (Field 7 en el Layout representado),  se ingresará unicamente un nombre o un texto a elección, de la misma manera que se ingresa cualquier elemento de texto.

Probando el funcionamiento del Smartform

Luego de haber creado el Smartform (siguiendo todos los pasos detallados en el presente tip),  y contando con el programa impresor (ya creado en el tip anterior: Cómo crear el programa impresor para la ejecución de un Smartform en SAP), es posible finalmente testear su funcionamiento, ejecutándolo.

1) Para ello,  será necesario acceder a la transacción SE80, selecionar el  programa impresor ya creado en el tip anterior que se lo denominó en el ejemplo ZIMPRESOR.

2) Al presionar F8 (Ejecutar) aparecerá la imagen siguiente, mostrando las opciones de impresión para imprimir el Smartform creado:

3) Sobre la imagen anterior, al Hacer click en “Print Preview”, se desplegará la imagen siguiente, que refleja la salida de la ejecución del smartform. Considerar que la disposición de las ventanas en la salida aquí obtenida puede variar, en consecuencia de lo que no se definió detalladamente en el tip presente, y dependerá en ese caso de lo que el desarrollador haya especificado para completar la definición del Smartform.

Para tener en cuenta ….

• Es importante considerar la utilización de la herramienta Form Painter que ayuda a defnir la ubicación y el tamaño de las ventanas. Se recomienda utilizarlo con criterio, porque un mal uso del mismo puede llevar a errores en el funcionamiento de Smartforms. Debido a esto en el presente tip se colocaron específicamente las medidas de una de las ventanas.
• Una buena práctica es utilizar un mismo patrón de medida para definir todos los elemento del smartform.

Especialista ABAP

Copyright 2012 - Teknoda S.A.