Evitar timeout Report

Consultas SAP
1

Buenas tardes,

os quería comentar una cosilla,a ver si me podeis ayudar, :).

Existe un report que tarda bastante en ejecutarse en productivo, dando error (dump) por timeout.

He investigado un poco por internet y he encontrado varias opciones para solucionarlo, pero ninguna sé si es correcta al 100%.

De las opciones que he visto, he elegido la opción de añadir el siguiente código dentro de mi loop (este loop es el que tarda bastante en ejecutarse):


    cl_progress_indicator=>progress_indicate( EXPORTING
                               i_text               = c_str
                               i_processed          = sy-tabix
                               i_total              = lines( lt_mayor )
                               i_output_immediately =  'X' ).

Quería saber si alguien ha utilizado la clase “cl_progress_indicator” para evitar el timeout…ya que el dump ( timeout ) solo ocurre en productivo y me gustaría subir algo que este OK, :).

Para vuestra información os pongo también el resto de opciones encontradas pero no probadas, por si las conocéis:

  • usar la función SAPGUI_PROGRESS_INDICATOR.
  • usar la funcion TH_REDISPATCH.

Gracias y un saludo,
Rafael.

1 me gusta
2

Hola,

Esas opciones… cl_progress_indicator=>progress_indicate o SAPGUI_PROGRESS_INDICATOR, hacen que te muestre el relojito abajo mostrando el progreso, y si, en algunos casos evita el timeout.

Pero como abaper, trataria de ver además, si hay posibilidades de mejorar la performance de ese programa, para que no tarde tanto, por ejemplo ¿hay algún select dentro de ese loop? lo ideal es tener los selects por fuera de los loops, guardando en tablas internas, y dentro del loop leer la tabla.

Por otro lado, a veces cuando se manejan grandes volúmenes de datos, es una buena opción manejarse por procesos de fondo.

Saludos,
Sebastián

2 Me gusta
3

Buenas @sconoredhot,

pues el tema es que por razones de empresa, no debemos tocar nada del código, ya que este mantenimiento lo lleva otra empresa externa, :smiley:…y antes de enviar el reporte a la empresa externa (y cobrar por sus servicios,jeje) quieren ver si somos capaces de evitar el timeout de alguna otra forma que no sea modificando el código.

Respondiendo a tu pregunta tengo que decirte que si, existen SELECT SINGLE dentro de LOOPS…pero como te digo queremos dar la solución sin tocar prácticamente nada del código.

Muchas gracias por la rápida respuesta!!

Un saludo,
Rafa.

4

Entonces hay algo que no entiendo,

Nos dices:
"De las opciones que he visto, he elegido la opción de añadir el siguiente código dentro de mi loop (este loop es el que tarda bastante en ejecutarse):

cl_progress_indicator=>progress_indicate( EXPORTING
                           i_text               = c_str
                           i_processed          = sy-tabix
                           i_total              = lines( lt_mayor )
                           i_output_immediately =  'X' )."

Eso significa modificar código. Y si van a modificar para agregar eso, también pueden ver la parte que te comento de mejorar el loop.
Si no van a modificar nada, no conozco manera de mejorar la performance de ese programa, desde el lado ABAP.

Saludos!
Sebastián

3 Me gusta
5

Buenas de nuevo @sconoredhot,

si perdona, no me he explicado correctamente. Me refiero a que mi responsable me ha pedido evitar modificar el código existente.

Por ello, habían pensado en esta solución, que no afecta al código existente y puede dar la solución.

Gracias y un saludo,
Rafa.

6

Voy con las ideas de Sconoredhot !!

Ahora, el error es solo en produccion ?? cuando prueban en calidad, tiene un escenarios parecido (digo en cuanto a registros) ??

1 me gusta
7

Buenas @canuto,

que va, no se puede reproducir el error en otro sistema que no sea Productivo, ya lo he intentado, :S.

Gracias y un saludo,
Rafa.

8

Bueno @rafbercar en ese caso, estando tan limitados, puedes intentar con la opcion que dices, pero no te asegura nada. Por otro lado, ¿no contemplaron la posibilidad de ejecutar el reporte de fondo?

9

ummmm bueno, echandole la culpa al codigo jejeje que debe estar para mejorar en algun punto porque si en produccion se cae (asumiendo que es una cantidad grande de registros) y produccion es un sistema con mejor rendiemiento que otros no me imagino en calidad por ejemplo, la cosa es que si no se puede replicar en calidad y probar…la culpa es del codigo jajaja !!

Si ustedes o tu no pueden modificar el codigo, pues no veo de otra que mandarselo a la empresa externa :S !!!

2 Me gusta
10

Pero en el entorno de QAS ¿no lo puedes reproducir? ¿no teneis los mismos datos? Porque si teneis los mismos datos y en QAS no se produce, puede ser entonces que haya que cambiar algo del perfil de instancia

11

Pues no tengo ni idea @sconoredhot…solo me han indicado lo justo para solucionar la incidencia. :S.

1 me gusta
12

Buenas @Salco,

en QAS no se puede reproducir el error porque no existen los mismos datos, :S. De todas formas mientras se decide que hacer con la subida estoy intentando buscar en QAS datos de prueba para reproducir el dump, pero es una locura,jejeje.

Gracias y un saludo,
Rafa.

13

Pero @rafbercar ¿no podeis hacer una copia de mandante?

1 me gusta
14

ES verdad @Salco eso hacemos cada 3 o 4 meses en mi empresa, copiamos todos los datos de PRD a QAS… muy buena !

15

@sconoredhot nosotros lo podemos hacer cuando necesitemos :slight_smile:
En algunos momentos es genial porque podemos reproducir un error que se produjo el día anterior.

4 Me gusta
16

Buenas @salco,

no, no podemos hacer una copia del mandante, :S.

Saludos,
Rafael.

17

Buenas tardes chic@s,

os tengo que decir que se ha transportado a Productivo y se ha solventado el problema con el código que os puse en el post, :D.

Gracias a todos por la ayuda!!!

Marco el post como resuelto, :).

4 Me gusta
18

Este tema se cerró automáticamente 7 días después del último post. No se permiten nuevas respuestas.