Cómo transferir un Smartform a otro sistema SAP sin usar una OT

Conozca cómo puede llevar un Smartform (su definición y el estilo asociado) que fue creado en un sistema SAP, a otro sistema SAP, sin generar una Orden de Transporte.

A diferencia de los Sapscripts, los Smartforms son objetos INDEPENDIENTES de los mandantes definidos en el mismo sistema SAP, es decir que si se requiere utilizar el Smartform en otro mandante del mismo sistema, no es necesario hacer el transporte hacia ese mandante.

Sin embargo, ésto cambia si se trata de utilizar un Smartform que fue definido en un mandante de un sistema SAP (en un servidor determinado) y se requiere utilizar ese Smartform en OTRO sistema SAP (instalado en un servidor diferente). En este caso, sí va a ser necesario copiar dicho Smartform al servidor SAP de destino para poder utilizarlo.

Leer más...

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

ABAP Objects: Tutorial para implementar "exceptions"

En este Tutorial de ABAP Objects conoceremos qué es una excepción ("exception") y veremos en qué situaciones conviene usarlas. Además, aprenderemos a implementarlas en ABAP Objects, y probaremos su uso mediante dos ejemplos, paso a paso.

Una Excepción ("Exception") es un evento que ocurre durante la ejecución de un programa, que interrumpe el flujo normal de las instrucciones del mismo, cambiando su normal comportamiento. Cuando se produce una excepción (usualmente asociada a una condición de error), el programa termina inmediatamente, por lo tanto, es importante que esas situaciones puedan ser manejadas de alguna manera dentro del programa y evitar la cancelación del mismo.

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.

Matriz de versiones de productos SAP

Matriz de versiones vigentes o anunciadas de determinados productos y herramientas SAP - Agosto 2013

La funcionalidad de cualquier entorno SAP es altamente dependiente de las versiones y nivel de actualización de productos instalados. Es importantísimo para analistas, programadores, funcionales, BASIS, etc. poder conocer esta información para planificar, interpretar documentación, y saber los recursos de que dispone en su tarea.

La cantidad de productos que conforman la oferta de SAP, y la dinámica de actualización de los mismos, a menudo genera confusión para acceder y entender esta información. Esto se complica aún más si se considera para cada versión, su horizonte de mantenimiento, los upgrade paths, y la articulación de cada producto con otros, con las bases de datos, sistemas operativos, etc.

Debido a ello, como una ayuda para nuestros lectores, presentamos para cada herramienta/producto SAP una guía con la designación de las últimas versiones disponibles, los Enhancements Packages, y su proyección anunciada.

En realidad, la información aquí presentada surge de un complejo entramado de especificaciones que SAP vuelca en sus PAM (Product Availability Matrix). Las matrices de disponibilidad de productos son accesibles en el SAP Service Marketplace, donde la información figura con lujo de detalles para cada componente de la suite de productos.

Nuestra guía es un resumen de la misma, con los productos más importantes de la SAP Business Suite, y SAP HANA, que intenta ofrecer un formato de rápida y sencilla legibilidad. La idea es mantenerla actualizada incorporando información a medida que se liberen nuevos productos y versiones.

NOTA: Esta guía NO incluye información alguna sobre la funcionalidad específicamente agregada o incorporada en cada versión, requisitos de upgrade, etc., temas que por lo general se tratarán por separado en otros tips. Debe considerarse asimismo que la liberación de un determinado producto o paquete de actualizaciones no implica su disponibilidad inmediata en todos los países, por lo que pueden existir desfasajes según su ubicación geográfica.

Para quienes deseen acceder a la información completa, al final de la matriz, junto con las notas aclaratorias al pie presentamos los links de acceso a las PAM (Product Availability Matrix.)

NOTA IMPORTANTE: La matriz de productos presentada está actualizada a AGOSTO de 2013.

Notas aclaratorias:

(1)

• El producto de Software SAP CRM opera sobre ABAP y  sobre JAVA. Por lo tanto, si la instancia del producto es CRM ABAP Server o CRM JAVA Server (tanto para el producto en sí como para los EhP), dependiendo de la versión, se apoyarán en SAP Netweaver 7.0/7.01AS ABAP y AS JAVA o también en SAP Netweaver 7.0-7.01-7.02 / 7.3 AS JAVA.

(2)

• El producto de Software SAP SRM opera sobre ABAP y sobre JAVA. Por lo tanto, para la instancia de producto SRM Server (ABAP) y SRM Supplier Java, dependiendo de la versión , se apoyarán en SAP Netweaver 7.0 AS ABAP  o SAP Netweaver 7.0 - 7.01 - 7.02 -7.03  /7.3 AS JAVA
• Las versiones SAP SRM 4.0 y  SAP SRM 5.0 se encuentran en periodo de mantenimiento extendido, hasta Marzo de 2013 y Marzo de 2015, respectivamente.
• La versión SAP SRM 6.0 (2007) comienza a partir de Marzo de 2013, con mantenimiento extendido hasta Marzo de 2016.

Como mencionáramos anteriormente, la información recolectada en la matriz ofrecida en este artículo no incluye todos los productos de software provistos por SAP ni las consideraciones de upgrade, sistemas operativos y base de datos necesarias en cada caso. Puede obtener la información completa ofrecida por SAP accediendo a la Matriz de disponibilidad de productos de SAP (PAM)

Acceso a la PAM de SAP

Las matrices de disponibilidad de productos son accesibles en el SAP Service Marketplace, donde la información figura con lujo de detalles para cada componente de la suite de productos. Es importante considerar que la información ofrecida por SAP mediante la PAM está en permanente cambio, por lo tanto para tener acceso a la información actualizada, es importante chequearla con frecuencia.

La versión actual de PAM ofrecida por SAP es la versión PAM 2.0.

Accediendo directamente mediante el link https://websmp110.sap-ag.de/pam o (de manera más indirecta) a :http://service.sap.com/pam se llega a la ultima versión de PAM, donde encontrar totalmente actualizado la información sobre productos disponibles hasta el momento.

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

Dos escenarios de ABAP con SAP HANA

Las soluciones que integran el Application Server ABAP con SAP HANA van ganando protagonismo a medida que SAP HANA se posiciona, no sólo para aplicaciones analíticas sino también para la operatoria transaccional. SAP HANA puede articular con ABAP en dos escenarios conceptualmente bien distintos, pero en ambos casos, beneficiándose con la potencia del procesamiento "in-memory" para manejar grandes volúmenes de datos.

Pocas tecnologías tienen actualmente la vertiginosa dinámica de SAP HANA, cuya materialización en productos y soluciones está en constante cambio desde su lanzamiento en el año 2011. Además de la evolución intrínseca de SAP HANA como plataforma, existe una evolución paralela en los demás componentes SAP que deben articular con ella para configurar una solución. Tal es el caso del AS (Application Server) ABAP, que gana protagonismo a medida que SAP HANA se posiciona, no sólo para aplicaciones análíticas sino también para la operatoria transaccional.

Leer más...

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

ABAP OBJECTS: Pasando revista a sus conocimientos

"La mejor manera de predecir el futuro es inventarlo"  - ALAN KAY  /
"El mayor desafío de un científico de informática es no confundirse con las complejidades de su propia creación"   -  E. DIJKSTRA  /
"Controlar complejidad es la esencia de la programación informatica."   B. KERNINGHAM  /

Un barrido ordenado sobre los artículos y tutoriales de ABAP Objects es una excelente forma de pasar revista a sus conocimientos.

La programación orientada a objetos (POO) es una filosofía de diseño y desarrollo de software donde el modelo informático busca reflejar los objetos del mundo real.

Valiéndose de un lenguaje y  entorno que respete los principios de la teoría de objetos, la POO permite a los programadores representar cada entidad del problema a través de la definición de un objeto acorde. Objetos típicos del entorno de negocios son "Clientes", "Materiales", "Ordenes de compra", etc. La teoría de objetos se estructura alrededor de una larga lista de propiedades y paradigmas conceptuales, materializados luego en los distintos entornos de programación. Las ventajas de lla programación orientada a objetos que incluyen el encapsulamiento de la complejidad, la reusabilidad del código, la modularidad, entre otros.

El instrumento que disponemos en ABAP para trabajar de acuerdo a este paradigma son los  "ABAP Objects". La introducción de ABAP Objects en el Release 4.6, finalmente consolidada en la 6.1, representó tal vez el paso más significativo de modernización en el mundo de la programación ABAP.

Compendiamos en este tip los artículos más instructivos y relevantes sobre ABAP Objects para brindarle una forma ordenada de pasar revista a sus conocimientos sobre el tema.

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.