Lea en SAP Netweaver . . .

Desanudando Conceptos: SAP HANA

No hay “newsletter”, conferencia o evento del ambiente ERP que en los últimos meses haya ahorrado detalles y especulaciones sobre el nuevo paradigma: SAP HANA.

En medio del marketing “hype”, es siempre difícil para los que estamos en el ruedo decodificar lo esencial de las nuevas tecnologías, así que aquí va nuestro aporte para ayudar a una cabal y conceptual comprensión de SAP HANA.

FaceBookTwitterGoogle+

SAP Netweaver / ABAP                  Notas técnicas / Tips / Tutorials

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.

Decorator es un patrón de diseño que resuelve el problema de añadir dinámicamente funcionalidades adicionales a un objeto. Para ello, propone una solución al problema que consiste en encapsular la vista de texto en otro objeto que agrega el borde. En términos de programación dicha encapsulación es una relación de composición, la cual mediante polimorfismo, se puede llevar a cabo de manera dinámica.

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).

1-composicion_a

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

2-composicion_b

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

3-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:

4-diagrama_de_clases

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.

Nota: El presente tip supone que el lector ya se encuentra familiarizado en cómo crear clases, definir métodos y atributos. Si éste no es el caso, es recomendable la lectura del tip Tutorial ABAP Objects: Parte 2, en donde aprenderá esos conceptos necesarios para el seguimiento del presente Tutorial.

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:

 

5-creacion_interfaz_bebida

 

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:

6-interfaz_bebida_atributos

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

7-formato_price

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:

8-interfaz_bebida_metodos

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.

9-interfaz_bebida_metodos_parametros_y_get_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.

11-clase_cafe_metodos

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

12-clase_cafe_atributos_e_implementacion

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:

13-clase_cafe_metodo_constructor_parametros

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:

14-clase_ingrediente_metodos

Y la solapa de los atributos, como sigue:

16-clase_ingrediente_atributos

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:

17-clase_ingrediente_metodo_set_cafe_compuesto_parametros

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:

18-salida_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.


n_Guido-Falcucci Especialista ABAP

 

 

 


Copyright 2012 - Teknoda S.A.

IMPORTANTE:
“Notas técnicas de SAP ABAP" se envía con frecuencia variable y sin cargo como servicio a nuestros clientes SAP. Contiene notas/tutoriales/artículos técnicos desarrollados en forma totalmente objetiva e independiente. Teknoda es una organización de servicios de tecnología informática y NO comercializa hardware, software ni otros productos.
Si desea suscribir otra dirección de e-mail para que comience a recibir las Notas Técnicas SAP, envíe un mensaje desde esa direcciónsapping@teknoda.com, aclarando nombre, empresa, cargo y país del suscriptor.

SAP, SAP Netweaver, R/3 y ABAP son marcas registradas de SAP AG. SAP no es el editor de esta publicación y no es responsable de la misma en ningún aspecto. La información contenida en esta publicación ha sido generada por nuestros especialistas a partir de fuentes consideradas confiables y del ejercicio profesional cotidiano. No obstante, por la posibilidad de error humano, mecánico, cambio de versión u otro, Teknoda no garantiza la exactitud o completud de la misma.
COPYRIGHT TEKNODA S.A. PROHIBIDA SU REPRODUCCION TOTAL O PARCIAL SIN CONSENTIMIENTO DE TEKNODA


 

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)

 

FUNCION

MODULO FUNCION

SIGNIFICADO

GRUPO DE FUNCION

GRABACION

BAL_DB_SAVE

Grabar un log en la base de datos

SBAL_CNTL

CREACION

BAL_LOG_CREATE

Creacion de un log  con datos de cabecera

SBAL

BUSQUEDA

BAL_GLB_SEARCH_LOG

Buscar un log/s ( en memoria)

SBAL

BAL_GLB_SEARCH_MSG

Buscar un mensaje/s ( en memoria)

SBAL

BAL_DB_SEARCH

Buscar un log en la base de datos

SBAL_CNTL

INSERCION

BAL_LOG_MSG_ADD

Añadir los mensajes en el  log

SBAL

BAL_LOG_MSG_ADD_FREE_TEXT

Añadir los mensajes de texto libre en el log

SBAL

BAL_DB_LOAD

Cargar el log en la base de datos

SBAL_CNTL

BAL_LOG_EXCEPTION_ADD

Añadir las excepciones en el log

SBAL

LECTURA

BAL_HDR_READ

Leer los datos y textos de la cabecera del log

SBAL

BAL_MSG_READ

Leer los datos y textos del/los mensaje/s  del  log

SBAL

BAL_LOG_EXCEPTION_READ

Leer los datos y textos de la/s excepción/es del log

SBAL

MODIFICA-CION

BAL_LOG_MSG_CHANGE

Cambiar un mensaje de un log

SBAL

BAL_LOG_HDR_CHANGE

Cambiar un encabezado  de un log

SBAL

BAL_LOG_EXCEPTION_CHANGE

Cambiar una excepción  de un log

SBAL

VISUALIZA-CION

BAL_DSP_LOG_DISPLAY

Muestra  pantalla total de la salida del log.

SBAL_DB_INTERNAL

BAL_DSP_LOG_PARAMETERS

Muestra  los parametros de la cabecera del log.

 

SBAL_DB_INTERNAL

BAL_DSP_LOG_TECHNICAL_DATA

Muestra los datos tecnicos de la  cabecera del log

SBAL_DB_INTERNAL

BAL_DSP_MSG_PARAMETERS

Muestra  los parametros del/ los  mensaje/s  del log.

 

SBAL_DB_INTERNAL

BAL_DSP_MSG_TECHNICAL_DATA

Muestra los datos tecnicos del/los mensaje/s  del log.

SBAL_DB_INTERNAL

BORRADO

BAL_LOG_DELETE

Borrar  el log

SBAL_TOOLBOX

BAL_LOG_MSG_DELETE

Borrar el mensaje del log

SBAL

BAL_LOG_MSG_DELETE_ALL

Borrar  todos los mensajes del log

SBAL

BAL_LOG_REFRESH

Borrar el log de la memoria

SBAL

BAL_LOG_EXCEPTION_DELETE

Borrar excepcion del log

SBAL

BAL_DB_DELETE

Borrar el log de la memoria

SBAL_CNTL

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 .

 

ABAP-Application-Log-creacion

 

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 .

 

ABAP-006-Create Program

 

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

 

ABAP-007-Display-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.

 


n_Luciana_Presa_Binda-1 Especialista ABAP

 


Copyright 2012 - Teknoda S.A.

IMPORTANTE:
“Notas técnicas de SAP ABAP" se envía con frecuencia variable y sin cargo como servicio a nuestros clientes SAP. Contiene notas/tutoriales/artículos técnicos desarrollados en forma totalmente objetiva e independiente. Teknoda es una organización de servicios de tecnología informática y NO comercializa hardware, software ni otros productos.
Si desea suscribir otra dirección de e-mail para que comience a recibir las Notas Técnicas SAP, envíe un mensaje desde esa direcciónsapping@teknoda.com, aclarando nombre, empresa, cargo y país del suscriptor.

SAP, SAP Netweaver, R/3 y ABAP son marcas registradas de SAP AG. SAP no es el editor de esta publicación y no es responsable de la misma en ningún aspecto. La información contenida en esta publicación ha sido generada por nuestros especialistas a partir de fuentes consideradas confiables y del ejercicio profesional cotidiano. No obstante, por la posibilidad de error humano, mecánico, cambio de versión u otro, Teknoda no garantiza la exactitud o completud de la misma.
COPYRIGHT TEKNODA S.A. PROHIBIDA SU REPRODUCCION TOTAL O PARCIAL SIN CONSENTIMIENTO DE TEKNODA


 

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”.

g01-abap-test-sequence

 

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.

g04-ABAP-Select-Function-Module-secuencia-BAPIs

 

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.

g02-abap-test-sequence

 

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)

 

g03-aba-test-sequence

 

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).

g05-abap-test-sequence

 

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.

g12-ABAP-Boton-Atras

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:

 

g13-Cargar-X-BAPI_TRANSACTION_COMMIT

 

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

g14-ABAP-Proceso-Completado

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.

n_Nelson-Ramos Especialista ABAP
n_Diego-Perez Especialista ABAP

 

 

 

 


Copyright 2012 - Teknoda S.A.

IMPORTANTE:
“Notas técnicas de SAP ABAP" se envía con frecuencia variable y sin cargo como servicio a nuestros clientes SAP. Contiene notas/tutoriales/artículos técnicos desarrollados en forma totalmente objetiva e independiente. Teknoda es una organización de servicios de tecnología informática y NO comercializa hardware, software ni otros productos.
Si desea suscribir otra dirección de e-mail para que comience a recibir las Notas Técnicas SAP, envíe un mensaje desde esa direcciónsapping@teknoda.com, aclarando nombre, empresa, cargo y país del suscriptor.

SAP, SAP Netweaver, R/3 y ABAP son marcas registradas de SAP AG. SAP no es el editor de esta publicación y no es responsable de la misma en ningún aspecto. La información contenida en esta publicación ha sido generada por nuestros especialistas a partir de fuentes consideradas confiables y del ejercicio profesional cotidiano. No obstante, por la posibilidad de error humano, mecánico, cambio de versión u otro, Teknoda no garantiza la exactitud o completud de la misma.
COPYRIGHT TEKNODA S.A. PROHIBIDA SU REPRODUCCION TOTAL O PARCIAL SIN CONSENTIMIENTO DE TEKNODA


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 ebook


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.

SAP Smart Forms fue introducido con el SAP Basis Release 4.6C como la herramienta estratégica para la creación y mantenimiento de formularios impresos.

Hasta entonces, SAPScript había sido el caballito de batalla a la hora de resolver esta tarea, y su funcionalidad resultó más que interesante para su época de vigencia, permitiendo un cierto grado de separación entre el manejo de los datos y el diseño de formularios.

 

Con Smartforms SAP redobla la apuesta, con una interfaz gráfica que permite el diseño visual de los formularios, el tratamientos de gráficos, el soporte de Internet, en muchos casos sin ningún esfuerzo de programación.

A diferencia de SAPScript, los formularios definidos con Smartforms controlan también la lógica de impresión del documento, fuera del programa ABAP. SmartForms introduce la posibilidad de “embeber” en el formulario código para manejar situaciones especiales en la lógica de impresión, y eliminando la necesidad del programa impresor requerido por SAPScript.

En muchas instalaciones, sin embargo, todavía conviven ambas herramientas, y por lo tanto, puede resultar útil puntualizar en forma breve las principales diferencias entre ambas..

Recomendamos la lectura de los siguientes tips, publicados anteriormente por Teknoda, para quienes deseen ampliar estos conceptos.

 

Resumen principales diferencias entre SmartForms y SAPScript

 

SAPScript

SmartForms

Dependencia del Cliente

SapScript es dependiente del cliente (Mandante). Sólo se puede generar un SAPScript en el cliente donde fue creado.

Smartforms es independiente del Cliente. La generación del function module puede hacerse en cualquier cliente mientras esté en el mismo sistema SAP.

Ventana principal

Requieren una ventana principal

Es posible tener un smartform sin una ventana principal.

Lógica del formulario (Form Logic)

En Sapscript la lógica necesaria se incorpora con el programa impresor, que es obligatorio. Cualquier modificación en el formulario exige hacer cambios en el programa y en el formulario.

No requiere un programa separado, se puede ingresar el código directamente en el Smartform y se pueden escribir rutinas con las herramientas disponibles.

Interfaz para diseño

Los elementos de texto se definen en ventanas sin ningún orden en particular. Esto se puede ver en la ventana principal solamente.

Utiliza interfaz gráfica, a través del Form Painter y el Graphical Table Painter.

Los nodos en SmartForms son como los elementos de texto en SAPScript. Estos nodos contienen lógica correspondiente, por lo que crear los nodos consume más tiempo que los textos en Sapscript.

Mantenimiento

Es mas tedioso mantenerlo si requiere cambios, ya que es más complejo

Es más fácil de mantener debido a la lógica dentro de su forma.

Conocimienos de programación requeridos

Es más tediosa la codificación del programa impresor y la creación del formulario. No es tan gráfico ni elegante.

El conocimiento de programación es mínimo debido a la interfaz gráfica.  El diseño y su lógica son apoyados por las herramientas gráficas. Smartforms es mucho más fácil de usar.

Programa Impresor

El Programa impresor exige de 4 A 5 funciones ( OPEN_FORM, START_FORM, WRITE_FORM , END_FORM, “CLOSE_FORM” ) para la obtención del formulario.

El Programa impresor requiere 2 funciones (lc_name "rs38l_fnam", SSF_FUNCTION_MODULE_NAME ) para la obtención del formulario.

Conversiones

Un SAPScrip puede ser migrado a Smartform y un SAPScript Style puede convertirse en un Smart Style

No se puede migrar de SmartForms a Sapscripts.

Múltiples formatos de página.

No soportados

Soportados

Gráficos de fondo. Textos coloreados

Soportados, pero con implementación más compleja.

Soportados, con implementación simple.

Medios de salida

Los medios de salida de SAPScript son solamente la impresora y el fax.

Los medios de salida SmartForm son la impresora, el fax, E-Mail, y HTML..

Extracción de datos

En SAPScript para la extracción de datos se utilizan las tablas internas para pasar datos del programa al formulario.

Para la transferencia de datos entre el programa impresor y el Smartform, se utilizan estructuras planas (en el caso de usar un programa impresor).

Invocación

La llamada a un sapscript requiere un OPEN_FORM, START_FORM, WRITE de los elementos y END y CLOSE_FORM.

La llamada a un SmartForm y el paso de parámetros es mucho mas "limpio" y claro

Etiquetas

Sí se pueden crear etiquetas en SapScript.

No se pueden crear etiquetas en Smartforms

Conversión a XML

Mediante el uso de un programa (RSTXSCRP) Mediante la interfaz de Smartforms.

Reutilización de estilos

No es posible reutilizar estilos. Se definen en cada Sapscript.

Se pueden definir estilos globalmente, mediante la Tx SMARTSTYLES y luego utilizarlos en otros Smartforms.



Copyright 2012 - Teknoda S.A.

IMPORTANTE:
“Notas técnicas de SAP ABAP" se envía con frecuencia variable y sin cargo como servicio a nuestros clientes SAP. Contiene notas/tutoriales/artículos técnicos desarrollados en forma totalmente objetiva e independiente. Teknoda es una organización de servicios de tecnología informática y NO comercializa hardware, software ni otros productos.
Si desea suscribir otra dirección de e-mail para que comience a recibir las Notas Técnicas SAP, envíe un mensaje desde esa direcciónsapping@teknoda.com, aclarando nombre, empresa, cargo y país del suscriptor.

SAP, SAP Netweaver, R/3 y ABAP son marcas registradas de SAP AG. SAP no es el editor de esta publicación y no es responsable de la misma en ningún aspecto. La información contenida en esta publicación ha sido generada por nuestros especialistas a partir de fuentes consideradas confiables y del ejercicio profesional cotidiano. No obstante, por la posibilidad de error humano, mecánico, cambio de versión u otro, Teknoda no garantiza la exactitud o completud de la misma.
COPYRIGHT TEKNODA S.A. PROHIBIDA SU REPRODUCCION TOTAL O PARCIAL SIN CONSENTIMIENTO DE TEKNODA

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.

ABAP-Crear-smartform-1

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:

ABAP-Form-Attributes-2

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.

ABAP-Form-Interface-Solapas-3

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:

ABAP-Form-Interface-Tables-4

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:

ABAP-Global-definitions-5

 

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):

ABAP-Pages-And-Windows-6

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:

ABAP-Layout-smartform-7

 

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):

ABAP-Estructura1-8

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.

ABAP-Crear-Window-9

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

ABAP-Window-10

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

 

ABAP-Form-Painter

ABAP-Form-Painter-2

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.

ABAP-Crear-Text-11

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

ABAP-Text1-12

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:

 

ABAP-Escribir-Text-14

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:

ABAP-Texto-titulo-Flights-15

Una vez escrito el texto, habrá que volver hacia atrás ABAP-boton-Atras-16

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:

Layout-Smartform-Ventana-2

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:

ABAP-Crear-Template-17

Como resultado aparecerá la pantalla con el Template creado:

ABAP-Template-18

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

ABAP-Estructura2-19

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.

Es importante destacar que el template o cualquier otro elemento definido en el smartform, no podrá ser más grande que la ventana que los contiene (ni en alto ni en ancho), por eso en el paso siguiente se configurarán las dimensiones y ubicación de la ventana ya definida en pasos anteriores, con el objetivo de vincular la ventana con el template contenido en la misma de acuerdo a lo esperado y así evitar errores.

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

ABAP-Window-Template-20

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

ABAP-Output-Options-21

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:

ABAP-Configurar-Template-22

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

ABAP-Detalles-Configuracion-Template-24

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).

ABAP-Posicion-en-Template-25

  • 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:

ABAP-Estructura_MAIN-26

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:

ABAP-Smartform-MAIN-27

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

ABAP-Crear-Tabla-MAIN-28

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.:

ABAP-Chage-Tabla-GS_BOOK-29

4) Posteriormente, seleccionar la solapa “Data”:

ABAP-GS_BOOK-Data-30

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:

ABAP-GS_BOOK-Data-Loop-31

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":

ABAP-LTYPE-32

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)

ABAP-Line-Type-33

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

ABAP-Crear-Table-Line-34

 

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

ABAP-Line-Type-Header-35

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 )

ABAP_Header_Rows_Cells_Texts-36

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:

ABAP-Input-Header-37

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

ABAP_MainArea_Rows_Cells_Texts-38

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).

ABAP_Main_Area_Text-38Bis

 

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.

ABAP_Footer_Rows_Cells_Texts-39

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.

 

ABAP-Programa-ZImpresor-40

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

ABAP-Imprimir-41

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.

ABAP-smartform-final-42

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.

n_Diego-Perez Especialista ABAP

Copyright 2012 - Teknoda S.A.

IMPORTANTE:
“Notas técnicas de SAP ABAP" se envía con frecuencia variable y sin cargo como servicio a nuestros clientes SAP. Contiene notas/tutoriales/artículos técnicos desarrollados en forma totalmente objetiva e independiente. Teknoda es una organización de servicios de tecnología informática y NO comercializa hardware, software ni otros productos.
Si desea suscribir otra dirección de e-mail para que comience a recibir las Notas Técnicas SAP, envíe un mensaje desde esa direcciónsapping@teknoda.com, aclarando nombre, empresa, cargo y país del suscriptor.

SAP, SAP Netweaver, R/3 y ABAP son marcas registradas de SAP AG. SAP no es el editor de esta publicación y no es responsable de la misma en ningún aspecto. La información contenida en esta publicación ha sido generada por nuestros especialistas a partir de fuentes consideradas confiables y del ejercicio profesional cotidiano. No obstante, por la posibilidad de error humano, mecánico, cambio de versión u otro, Teknoda no garantiza la exactitud o completud de la misma.
COPYRIGHT TEKNODA S.A. PROHIBIDA SU REPRODUCCION TOTAL O PARCIAL SIN CONSENTIMIENTO DE TEKNODA


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...

Cómo crear el programa impresor para la ejecución de un Smartform en SAP

Aprenda paso a paso a crear el programa impresor para ejecutar un Smartform en SAP.

La herramienta Smartforms provista por SAP está enfocada en el desarrollo de formularios, por ejemplo el de una factura, que posteriormente será impresa de algún modo. Como medio de salida, los Smartforms soportan una impresora, un fax, e-mail o Internet (usando la salida XML).

Existen otras herramientas de SAP que posibilitan lo mismo, como Sapscript y Adobe Forms.

Para poder desarrollar un Smartform, es necesario previamente conocer algunos conceptos importantes:

El desarrollo de un Smartform consta de dos fases:

  • el diseño del formulario (layout)
  • y su invocación desde un programa ABAP. A este programa se lo denomina Programa Impresor o Programa de control. Es necesario tener creado este programa antes de poder utilizar el Smartform. Si bien la lógica implementada en este programa podría estar incorporada en el propio diseño del smartform, es habitual en la mayoría de las implementaciones de Smartforms, contar con un programa impresor específico que contenga esa lógica, "separada" del diseño específico del formulario.

El programa impresor o programa de control puede ser: desarrollado desde “cero” o adaptado de alguno existente.

Este programa, además de encargarse de realizar la llamada al Smartform, puede contener la lógica necesaria para la obtención de la información que el Smartform va a utilizar (por ejemplo, puede realizar consultas a la base de datos para extraer los datos a mostrarse en el Smartform). Los datos extraídos por el programa impresor se almacenarán en estructuras de datos (tabla interna, variables, etc.), y será enviada al Smartform para que éste pueda usar esa información.

Sin embargo, como se mencionó en párrafos anteriores, el mismo diseño del Smartform podría contener esa lógica para la obtención de información que él mismo va a utilizar.

En el presente tip se desarrollará paso a paso la creación de un programa impresor, explicando las principales sentencias de su código, ejemplificando la obtención de los datos a través de un programa impresor (no en el propio Smartform), que será generado desde cero.

Proximamente, en otro tip se detallarán los pasos necesarios para la definición del diseño propiamente dicho del formulario smartform.

Consideraciones para el Ejemplo a desarrollar:

Se trabaja con la tabla SBOOK del entorno de pruebas y se requiere que el diseño del formulario smartform a desarrollar respete el siguiente “layout”, y deberá recuperar los datos necesarios para listar las reservas correspondientes a los vuelos con los siguientes datos:

Compañía (campo carrid): Lufthansa (LH)

Connection Id (campo carrid): 0400

Fecha (campo fldate): 28 de Febrero de 1995.

ABAP-Layout-smartform

 

Pasos para la creación del programa Impresor:

1) Acceder a la transacción SE80 para crear un programa, denominado, por ejemplo, ZIMPRESOR, que será el programa Impresor del Smartform.

ABAP-Crear-Programa-Impresor-2

2) En este paso, una vez creado el programa impresor, será necesario en él realizar lo siguiente::

a) Definir las estructuras de datos, donde almacenar los datos obtenidos.

b) Obtener los datos (con consultas a la base de datos).

c) Especificar las funciones que llaman al Smartform

A continuación se detalla para a), b) y c) el código para realizar la acción correspondiente:

a) Definir las estructuras de datos:

Se detallan las siguientes sentencias dentro del programa impresor:

 

ABAP-Codigo-Definicion-datos-3-1

 

Donde se puede observar:

  • la creación de 3 variables (date1, carrier1 y connection1) para almacenar los datos únicos que se van a mostrar en el formulario. En la imagen del layout de salida mostrada anteriormente, se corresponde con los campos: Field 1, Field 2 y Field 3. El Field 7, también mostrado, no va a contener ningún dato en particular, pero es donde el desarrollador puede escribir su nombre o algún texto que sea de su interés. Este campo se incluye únicamente debido a que contribuirá luego, cuando se defina la estructura del Smartform, a detallar una de sus partes (por ejemplo, el “footer”).
  • La creación de una variable llamada l_funcion cuyo tipo es rs38l_fnam, contendrá  el nombre del módulo de función que ejecuta al Smartform.
  • La definición de un tipo de datos que coincide con la estructura de la tabla SBOOK (se usa de esta manera para simplificar el ejemplo).
  • Se declara una tabla interna del tipo definido en el código ejemplo.

b) Obtención de los datos:

ABAP-Codigo-Seleccion-4-1

 

En el código anterior se puede observar:

  • Se asigna a cada una de las variables creadas en el paso a) los valores que se solicitaron en el requerimiento ejemplo.
  • date1 se corresponde con la fecha, currier1 se corresponde con Compañia y connection1 se corresponde con Connection ID
  • La sentencia SELECT  obtiene los datos que se almacenarán en la tabla interna.

c) Especificar las funciones que llaman al Smartform

ABAP-Codigo-imprimir_formulario-5

La sentencia PERFORM imprimir_formulario es la que invoca a las funciones: 1) SSF_FUNCTION_MODULE_NAME (standard de SAP) y 2) l_funcion (definición propia), que son necesarias para la invocación de cualquier Smartform. (Tener en cuenta que l_funcion puede llevar otro nombre).

Se detalla esta acción en el código siguiente:

ABAP-Codigo-SSF_FUNCTION-6

 

Donde:

Para la función 1) SSF_FUNCTION_MODULE_NAME, se definen los parámetros necesarios:

  • el nombre del formulario (formname) – se introduce el nombre que se le dará al Smartform una vez que se lo cree.
  • el parámetro fm_name, que en este ejemplo en particular se definirá como l_funcion, como fue declarada anteriormente de tipo s38l_fnam.

 

Por último se declara el manejo de excepciones para la función.:

ABAP-Codigo-l_funcion-7

Como se visualiza en el código anterior:

  • Inmediatamente debajo del llamado a la función, será necesario chequear que no haya habido errores (sy-subrc = 0) y en ese caso se hará un call function a l_funcion (se corresponde con el “IMPORTING” de la función anterior).
  • En EXPORTING se detallan los campos que se desean enviar al Smartform.
  • En TABLES la tabla interna anteriormente definida, y como es habitual, el manejo de las excepciones correspondientes.

De esta manera el programa impresor está listo para ser utilizado para ejecutar un smartform.

Para tener en cuenta ...

  • El programa impresor es necesario para la ejecución de un Smartform, pero no es suficiente, resta crear el smartform (definiendo el diseño), para que pueda ser invocado por el Programa impresor.
  • Si bien la lógica definida en el programa impresor puede estar incorporada al diseñar el smartform, es habitual crear su lógica en el programa impresor como se detalló en el tip presente.

En el próximo tip se mostrará paso a paso cómo definir el smartform (diseñar el “layout”), para luego poder ejecutarlo, haciendo su invocación desde el programa impresor recientemente creado.


n_Diego-Perez Especialista ABAP

 

 

 

 


Copyright 2012 - Teknoda S.A.

IMPORTANTE:
“Notas técnicas de SAP ABAP" se envía con frecuencia variable y sin cargo como servicio a nuestros clientes SAP. Contiene notas/tutoriales/artículos técnicos desarrollados en forma totalmente objetiva e independiente. Teknoda es una organización de servicios de tecnología informática y NO comercializa hardware, software ni otros productos.
Si desea suscribir otra dirección de e-mail para que comience a recibir las Notas Técnicas SAP, envíe un mensaje desde esa direcciónsapping@teknoda.com, aclarando nombre, empresa, cargo y país del suscriptor.

SAP, SAP Netweaver, R/3 y ABAP son marcas registradas de SAP AG. SAP no es el editor de esta publicación y no es responsable de la misma en ningún aspecto. La información contenida en esta publicación ha sido generada por nuestros especialistas a partir de fuentes consideradas confiables y del ejercicio profesional cotidiano. No obstante, por la posibilidad de error humano, mecánico, cambio de versión u otro, Teknoda no garantiza la exactitud o completud de la misma.
COPYRIGHT TEKNODA S.A. PROHIBIDA SU REPRODUCCION TOTAL O PARCIAL SIN CONSENTIMIENTO DE TEKNODA


Copyright © 2018 Teknoda tips - Tecnologia SAP Netweaver - IBM AS400 - System i - iSeries - IBM i Power Systems. Todos los derechos reservados.
Joomla! es software libre, liberado bajo la GNU General Public License.