Durante estos últimos días se ha presentado un problema a la hora de implementar una mejora en un cluster de vistas. La mejora consistía en agregar un botón en cada dynpro que compone el cluster para que al hacer clic se llamase a un programa Z creado previamente que permite cargar datos a una tabla cualquiera del diccionario de datos desde archivos en formato Excel, tanto en formato nativo XLS como texto tabulado.
La primera decisión que se tomó, tras realizar las pruebas pertinentes, fue crear una transacción para poder hacer un CALL TRANSACTION ya que al hacer un SUBMIT AND RETURN se producía un error nada más iniciar el programa ya que no se habían informado los campos obligatorios pertinentes y no se deseaba que el usuario viera ese error.
Por lo tanto, se modificaron las dynpros previamente creadas con el “Generador de dialogos de actualización” que proporciona SAP para insertar en cada una de ellas un botón que al ser pulsado llamase a una subrutina que implementaba el CALL TRANSACTION.
Tras volver de ese programa era cuando el problema se presentaba: Se había cargado correctamente la tabla de diccionario de datos, pero los cambios no se reflejaban hasta que el usuario entraba de nuevo en el cluster. Obviamente esto no era lo ideal para una interacción correcta, así que se comenzó a buscar una solución.
Tras estudiar las subrutinas estándar se dió con parte de la solución. SAP crea una subrutina GET_DATA_*, cuyo nombre depende de la vista que se vaya a actualizar, que se encarga de cargar los datos a la tabla interna TOTAL propia de los dialogos de actualización. Sin embargo, esta subrutina no actualizaba correctamente lo que el usuario ve por pantalla.
Se intentó actualizar la tabla interna EXTRACT a mano con el siguiente código fuente, introducido justo detrás del CALL TRANSACTION:
LOOP AT TOTAL.
EXTRACT = TOTAL.
APPEND EXTRACT.
ENDLOOP.
Pero el problema persistía. Se procedió pues a estudiar las subrutinas creadas de forma estándar por SAP a la hora de crear un dialogo de actualización y se dio con la subrutina FILL_EXTRACT que, como su nombre indica, se encarga de informar la tabla interna EXTRACT.
Al realizar la prueba llamando a esta subrutina en lugar de hacer el LOOP anterior se vio que, por fin, se actualizaba correctamente el table control.
Por lo tanto la solución adoptada para este caso particular es esta:
Se crea un módulo PBO para controlar la entrada del usuario y dentro del mismo, tras hacer el CALL TRANSACTION se realizan los pasos anteriormente descritos.
Por ejemplo, supóngase que la vista de actualización a actualizar, valga la redundancia, se llama ZV_VISTA_ACT. Para realizar la actualización y el CALL TRANSACTION se deberá crear un módulo PBO como el que sigue:
MODULE m_user_command OUTPUT.
*Se controla la entrada introducida por el usuario.
CASE sy-ucomm.
WHEN 'CLICK'
*Se llama a la transacción que se encarga de cargar la tabla de
*diccionario de datos.
CALL TRANSACTION 'Z_CARGAR_FICHERO'.
*Ahora con los datos ya cargados se llama a las dos subrutinas
*estándar
PERFORM get_data_zv_vista_act.
PERFORM fill_extract.
ENDCASE.
ENDMODULE.
Ambas subrutinas son estándar, creadas por SAP a la hora de generar un diálogo de actualización, por lo tanto, siempre van a existir para un diálogo concreto con la forma:
GET_DATA_*
FILL_EXTRACT.
Siendo la primera dependiente del nombre de la vista de actualización en la que se informarán datos, ya que la parte final del nombre de la subrutina será el nombre de dicha vista.
