Hola,
Una solución un tanto "no elegante" sería que la función se apoye en una tabla de control donde se almacene el estado de llamadas (algo así deben tener los controles de los lenguajes que permiten recursividad).
La tabla que sugiero sería una tabla transparente con dos campos:
Usuario
Número de instancias
El procedimiento sería:
1. Al iniciar la función consulta la tabla con el nombre de usuario actual
2. Si el "número de instancias":
Caso A. Está en cero, todo está correcto y se asigna "1" al número de instancias
Al terminar la ejecución de la función (inmediatamente antes de salir de la función) se asigna "0" al número de instancias
Caso B. No está en cero, se podría abortar la función informando con un mensaje al usuario sobre la situación erronea
Con esto se impide que se ejecute doble, pero no se mata la instancia que quedó "pendiente".
Otro frente de investigación es investigar (con el equipo Basis) si hay algún parámetro general de sistema que determine el comportamiento al matar procesos "huerfanos" (procesos lanzados por un usuario y que se siguen ejecutando cuando el usuario ya se desconectó). Supongo que ese parámetro existe por razones obvias: si un cliente se bloquea deja procesos inconclusos en el servidor de aplicaciones. Posiblemente existan parámetros específicos para los RFC distintos de los correspondientes a sesiones normales abiertas a través del GUI.
Espero que estas sugerencias sean de ayuda aun cuando no son realmente soluciones sino ideas
Postdata: En todo caso la solución ideal y deseable es lograr que la función sea mas eficiente o que por lo menos informe al usuario acerca del avance para que el usuario no se impaciente (una barra de avance o algo que informe al usuario que el proceso no está congelado)
Úlima edición por abapedro fecha: 15/07/07 a las 03:51:24.
|