Transacciones para Queries

Hola!

Después de un largo tiempo, vuelvo a publicar un nuevo consejo.

En este caso les comento cómo crear una transacción para queries creados mediante las transacciones SQ01 y SQ02 (no sirve para la SQVI - no se pueden transportar estos queries de manera prolija).
Para transportar los queries, lo correcto es crear una transacción y luego transportar la transacción. La forma de crear la transacción no es buscando el nombre del programa que genera el query y asignarlo a la transacción, sino utilizando el tipo de transacción "Transacción de Parámetros" para la transacción "START_REPORT". Marcamos el tilde "Omitir imagen inicial" y usamos los siguientes valores de propuesta para los campos de la dynpro:

D_SREPOVARI-REPORT-> Nombre del Grupo de Usuarios del Query
D_SREPOVARI-EXTDREPORT-> Nombre del query
D_SREPOVARI-REPORTTYPE = "AQ" (de ABAP Query)

Hay que tener en cuenta el ámbito funcional con el que se creó el query. El mismo está en la transacción SQ01 en Entorno->Ambitos Funcionales.
Existen 2 posibiidades:

• Ambito estándar
• Ambito Global

En general se debe usar el segundo porque es mejor para poder transportar todos los objetos del query. Dependiendo del ámbito funcional, el parámetro D_SREPOVARI-REPORT varía.
Para el ámbito estándar, se pone directamente el nombre del grupo de usuarios; pero para ámbito global se debe poner una G (g mayúscula) en la posición 12 de la variable D_SREPOVARI-REPORT. Si no hacen esto, aparecerá un mensaje diciendo que no existe el grupo de usuarios.

Esta forma de crear transacciones para queries es la correcta porque si ponemos el nombre del programa directamente, nos va a traer problemas a la hora de transportar la transacción porque el nombre del programa generado por el query depende del ambiente y mandante.

Si tienen alguna dudao sugerencia, por favor escríbanme un comentario!

Debuggear procesos de fondo o jobs

Mediante este truco vamos a poder debuggear jobs de la transacción SM37.

Ir a la SM37, seleccionar el job en cuestión e ingresar en la línea de comandos de SAP "JDBG". Una vez ingresado este comando, el sistema abrirá un modo con el debugging para el job.

Esta técnica puede resultarnos muy útil cuando queremos debuggear un job, pero tiene como desventaja que si el job no nos da tiempo para realizar el truco vamos a tener que buscar otra solución. En ese caso, podemos intentar poner un WAIT o un loop infinito si estamos en un ambiente de pruebas...

Comenten si les resultó útil!

Saltear permisos en transacciones

Lo que viene es un truco para poder acceder a transacciones a las que no tenemos autorización.

Desde la transaccion SE37 (Funciones ABAP), ejecutar el módulo de funciones RS_HDSYS_CALL_TC_VARIANT. Ingresar la transacción a la que queremos acceder en el parámetro TCODE y limpiar el parámetro AUTHORITY-CHECK. Presionar F8 para ejecutar la transacción y listo!

Les aconsejo que utilicen esto con cuidado, y NUNCA en un ambiente de producción.

Saludos!

Escriban si les parece útil!

Tip - Activar las funciones de precios de la VOFM

Este va a ser un post corto, pero muy útil.

Alguna vez les pasó que crean una rutina de precios o algún otro objeto de la VOFM para el esquema de SD, lo prueban en el entorno de desarrollo y cuando lo transportan a QA o Producción les da un DUMP o no funciona?

Bueno... la solución puede ser esta: ejecutar el reporte RV80HGEN en el sistema destino.

Este reporte lo que hace es "activar" las rutinas de la VOFM en el sistema en el que se ejecuta; esto es necesario para que funcionen estas funciones.

Otra solución es agregar en la orden de transporte un objeto R3TR XPRA RV80HGEN y esto hará que cuando se transporte la orden, se ejecute automáticamente el reporte en el sistema destino.

En esta ocasión les voy a pasar la dirección de un foro en la que pueden hacer todo tipo de preguntas y que intentaré contestar con la mayor brevedad posible:

Foro Programación SAP ABAP

BTE's - Business Transaction Events

Las BTE's, o Business Transaction Events son un tipo de extensión del sistema SAP. A diferencia de las BADI's, únicamente se puede modificar código con las BTE's; no es posible modificar dynpros o menúes.
Las BTE's están basadas en Módulos de Funciones y Productos, a diferencia de las BADI's que están basadas en objetos.
Al implementar una BTE, se debe crear una interfase para el módulo de funciones de la BTE. De esta manera, el sistema leé una tabla Z y llama dinámicamente la función implementada por el cliente.
Existe 2 tipos de interfases:
- Interfases de Publicación y Suscripción
- Interfases de Proceso

Las interfases de Publicación y Suscripción brindan información sobre eventos en particular, como la creación o la modificación de un documento. Por otro lado, las interfases de proceso se utilizan para reemplazar la lógica estándar de SAP por lógica de cliente.

En este link vas a encontrar más información acercar de las BTE's y todo lo relacionado con la programación ABAP:

Business Transaction Events - BTE's

Tipos de Transacciones SAP

Por pedido del público, voy a hacer un resumen de los tipos de transacciones en SAP:

Transacciones de Diálogo

Son las transacciones más comunes dentro del estándar de SAP. Estas transacciones están ligadas a una Dynpro (pantalla) de un programa ABAP. Al llamar a estas transacciones, se carga el programa ABAP y se llama a la Dynpro. De esta manera, una transacción de diálogo llama a una secuencia de pantallas más que a un programa. Sólo durante la lógica de las pantallas se llaman efectivamente los módulos de diálogo del programa. De hecho, se pueden asignar diferentes transacciones de diálogo al mismo programa.


Transacciones de Parámetros

Estas transacciones son llamadas a otras transacciones existentes con parámetros de entrada. Es decir que son llamadas a transacciones con parámetros definidos, pudiendo omitir la pantalla inicial de la transacción original.


Transacciones de Variantes

Son transacciones ya existentes llamadas con una variante anteriormente creada. Al acceder a una transacción de variante, se ejecuta la transacción subyacente con la variante en cuestión. En las variantes se pueden definir valores para los diferentes valores de las diferentes pantallas, cambiar los atributos de los elementos de pantalla, etc. Las transacciones de variante se mantienen con la transacción SHD0.


Transacciones de Reporte

Son transacciones que llaman a un Reporte ABAP. La transacción se debe mapear con la pantalla de selección de un programa ejecutable. Internamente, cuando se llama a este tipo de transacciones el sistema ejecuta un SUBMIT al programa ejecutable.


Transacciones Orientadas a Objetos (OO Transactions)

Este tipo de transacciones apareció en la versión 6.10 de SAP. La transacción está linkeada a un método de una clase local o global. Cuando se llama a la transacción se carga el programa correspondiente.

En el siguiente link tiene más información acerca de las transacciones, tipos programas y ejemplos de código ABAP:

Ejemplos de ABAP

BADI's (Business ADd Ins)

Las BADI's (Business ADd Ins) son un nuevo tipo de extensión al sistema SAP basado en ABAP Objetcs. El objetivo de los mismos es cumplir con los requerimientos del cliente permitiendo agregar nuevas funcionalidades dentro del código estándar de SAP.
De la misma manera que con los User Exit's, las BADI's tienen dos vistas: la de definición y la de implementación. Mediante la transacción SE18 accedemos a la Definición de las BADI's. Allí se puede ver las características de la misma: parámetros de entrada, salida, tipo de BADI, etc. En la Implementación de la BADI, a la que se accede mediante la transacción SE19, se pueden ver todas las implementaciones que existan de una BADI determinada.

La definición de las BADI's viene definida en el sistema estándar (muy pocas veces es necesario crear una nueva definición para una BADI). En la definición se indica si la BADI es de implementación simple (se puede utilizar sólo una vez, como los User Exits) o múltiple (pueden existir varias implementaciones activas de la misma BADI en el mismo sistema). Además, se pueden definir filtros para la ejecución de la misma permitiendo de esta forma tener diferentes procesos para, por ejemplo, países diferentes. Esto le permite a SAP poder utilizar las BADI's para realizar localizaciones del sistema; por eso es que el sistema estándar ya incluye varias implementaciones de BADI's.

Mediante las implementaciones de BADI's también se pueden hacer aplicaciones para negocios específicos (papeleras, petroleras, químicas, etc). Esto hace que las BADI's sean muy útiles. Esto es así porque a diferencia de los User Exits las BADI's poseen una arquitectura Multicapa (SAP, partners, soluciones de clientes, localizaciones, soluciones específicas para industrias, etc); los User Exits son doble capa únicamente (SAP y soluciones de cliente).

En www.todoabap.com.ar van a encontrar métodos para encontrar las BADI's de una transacción o programa.