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.

1. Se han de seleccionar diferentes campos de una tabla en función de unas condiciones determinadas.
2. Se ha de seleccionar de una tabla de base de datos diferente en función de unas condiciones determinadas.
3. Se han de contemplar diferentes condiciones de selección en función de unas condiciones determinadas.

Las condiciones pueden ser variadas, pero las más comunes son determinadas por la entrada introducida por el usuario. El poder acceder de manera dinámica a la base de datos propicia mucho la reutilización de código, aunque puede tener desventajas de cara al mantenimiento de los programas y por lo tanto se hace necesaria una extensa y comprensible documentación en aquellos que se utilice este recurso.

A continuación se expone cómo realizar la selección dinámica para cada caso de los comentados anteriormente:

Selección con campos a recuperar dinámicos

APPEND ‘bukrs belnr dmbtr’ TO sel_list.

SELECT (sel_list)
FROM bseg UP TO 100 ROWS
INTO CORRESPONDING FIELDS OF TABLE li_bseg.

En este primer ejemplo los campos a recuperar se almacenan en la variable sel_list que se usa más tarde para llevar a cabo la selección. Se intuye la potencia de esta opción si en lugar de esta selección simple se complica un poco más el código

CASE v_flag.
WHEN c_flag_a.
APPEND 'bukrs belnr' TO sel_list.
WHEN c_flag_b.
APPEND 'belnr dmbtr' TO sel_list.
WHEN OTHERS.
APPEND ‘bukrs belnr dmbtr’ TO sel_list.
ENDCASE.

SELECT (sel_list)
FROM bseg UP TO 100 ROWS
INTO CORRESPONDING FIELDS OF TABLE li_bseg.

En este segundo ejemplo la lista de campos a recuperar varía en función del valor de la variable v_flag permitiendo recoger unos campos u otros en función de su valor. En la mayoría de los casos esto se puede usar para crear un FORM en el que dependiendo de un parámetro de entrada se realice una selección u otra diferente devolviendo una tabla con los valores deseados.

Selección con tabla fuente dinámica

FORM f_numero_de_entradas USING p_tabla TYPE string CHANGING p_numero TYPE I.
SELECT count(*) FROM p_tabla INTO p_numero.
ENDFORM

En este ejemplo se muestra un FORM que devuelve el número de entradas de una tabla pasada por parámetro. De nuevo se puede apreciar la potencia de la selección dinámica para realizar accesos a la base de datos.

La generalización anterior, considerada en el segundo ejemplo del primer caso, es también perfectamente válida para este caso, obteniendo de nuevo una gran flexibilidad y también un alto nivel de reutilización de código fuente.

Selección con condiciones dinámicas

Este caso es el más utilizado, ya que permite modificar las condiciones de selección en función de las condiciones que el programador crea oportunas, y que normalmente dependerán de lo introducido por pantalla por el usuario.

SELECTION-SCREEN BEGIN OF BLOCK bl_sel.
PARAMETERS: p_num_art TYPE xfeld RADIOBUTTON GROUP rbg1 DEFAULT 'X',
p_ean11 TYPE xfeld RADIOBUTTON GROUP rbg1.
SELECTION-SCREEN END OF BLOCK bl_sel.

DATA: where_clause TYPE string,
i_mara TYPE mara OCCURS 0.

START-OF-SELECTION.

IF p_num_art IS NOT INITIAL.
where_clause = "WHERE MATNR = 00012'.
ENDIF.

IF p_ean11 IS NOT INITIAL.
where_clause = 'WHERE EAN11 = 0842734892374'.
ENDIF.

SELECT *
INTO TABLE i_mara
FROM mara
(where_clause).

En el ejemplo se ve cómo la cláusula WHERE varía en función de si el usuario ha elegido p_num_art, seleccionar el artículo cuyo código de artículo sea 00012, ó p_ean11, seleccionar el artículo cuyo número de artículo europeo (EAN) sea 0842734892374. De nuevo se aprecia la potencia que la selección dinámica encierra.

Es posible además crear la cláusula WHERE concatenando en una variable todas las condiciones que deseemos contemplar, como por ejemplo:

where_clause = "WHERE matnr = 0012"
IF p_flag_1 IS NOT INITIAL.
CONCATENATE where_clause 'OR ean11 = 0987654321' INTO where_clause SEPARATED BY space.
ELSE.
CONCATENATE where_clause 'OR ean11 = 1234567890' INTO where_clause SEPARATED BY space.
ENDIF.

En este fragmento de código se define lo siguiente:

1. Si p_flag_1 está seleccionado se buscará el artículo cuyo código de artículo sea 0012 o cuyo EAN sea 0987654321.
2. Si p_flag_1 no está seleccionado se buscará el rtículo cuyo código de artículo sea 0012 o cuyo EAN sea 1234567890.

Evidentemente las tres se pueden combinar entre ellas, creando una selección potente, flexible y eficaz que permite reutilizar código y responder a las necesidades del usuario. Sin embargo tanta potencia implica que el programador deberá controlar muy bien los errores que puedan producirse y reaccionar ante ellos, pasando quizá a una selección estática o mostrando un mensaje de error por pantalla por ejemplo.

A la hora de crear una tabla dinámica, lo primero que se debe hacer es declarar las variables que van a servir para su construcción:

DATA: lv_tabla TYPE dd02l-tabname,
generic_table TYPE REF TO data,
generic_line TYPE REF TO data.

La variable lv_tabla contiene el nombre de la tabla de diccionario de datos que se usará como base para la creación de la tabla interna. Las variables generic_table y generic_line son referencias a una tabla y a una linea o área de trabajo genéricas. Estas dos últimas variables no son accesibles realmente, y por lo tanto es necesario declarar FIELD-SYMBOLS que servirán como manejadores a la hora de cargar y acceder a los datos.

FIELD-SYMBOLS: <table> TYPE ANY TABLE,
<wa> TYPE ANY,
<field> TYPE ANY.

Estos FIELD-SYMBOLS representan a la tabla completa, a un registro dentro de la tabla y a un campo concreto dentro de un registro respectivamente. Sin embargo inicialmente estarán sin asignar y si se intenta mostrar su valor u operar con ellos se producirá un error en tiempo de ejecución. Por lo tanto se debe conocer la forma correcta de asignar y manejar un FIELD-SYMBOL en SAP.

Obviamente, al construir una tabla interna se pretende que almacene datos bien obtenidos desde la base de datos o bien calculados por el propio programa Z. En el segundo caso es bastante probable que el programador ya sepa en tiempo de compilación qué datos tiene que calcular y en qué orden debe de almacenarlos en memoria, así que este tutorial se centra en el primer caso: Recuperar datos desde la base de datos a una tabla dinámica.

Para la generación de la tabla dinámica en tiempo de ejecución partimos del supuesto de que en la variable lv_tabla se encuentra el nombre de la tabla o estructura del diccionario de datos a partir de la cual se desea crear la tabla interna. Para su construcción se aplicará el siguiente fragmento de código ABAP

CREATE DATA generic_table TYPE STANDARD TABLE OF (lv_tabla).
ASSIGN generic_table->* TO <table>.

CREATE DATA generic_line TYPE (lv_tabla).
ASSIGN generic_line->* TO <wa>.

En este momento la variable generic_table será una tabla interna con la estructura de lv_tabla y generic_line será un registro de dicha tabla interna. Además los FIELD-SYMBOLS <table> y <wa> se encontrarán inicializados apuntando a la tabla y al área de trabajo respectivamente. En este momento se puede operar con dichos FIELD-SYMBOLS.

En este momento es cuando el programador puede cargar la información en la tabla interna de la forma habitual, teniendo en cuenta de que la selección tendrá una cláusula FROM dinámica, tal y cómo se puede apreciar en el siguiente fragmento de código:

SELECT *
INTO CORRESPONDING FIELDS OF TABLE <table>
FROM (lv_tabla).

Al tratarse de una selección dinámica, es conveniente que el programador trate las excepciones que se pueden producir, en este caso concreto, que no exista la tabla de base de datos indicada en lv_tabla.

A la hora de acceder a los datos de una tabla dinámica creada en tiempo de ejecución puede darse uno de dos casos:

1. El programador conoce el nombre de los campos de la tabla interna
2. El programador no conoce el nombre de los campos de la tabla interna.

En el primer caso el acceso al campo deseado se realizará de la siguiente forma:

CONSTANTS: lv_nombre_campo(255) TYPE C VALUE 'nombre del campo'.

DATA: lv_valor_campo TYPE tipo_del_campo.

LOOP AT <table> INTO <wa>.
ASSIGN COMPONENT lv_nombre_campo OF STRUCTURE <wa> TO <field>.
MOVE <field> TO lv_valor_campo.
ENDLOOP.

En el segundo caso el acceso será parecido, sólo que en lugar de utilizar el nombre del campo se utilizará un índice para el acceso. Dicho índice representa la posición del campo dentro de un registro de la tabla interna creada.

DATA: lv_indice_campo TYPE I,
lv_valor_campo. TYPE tipo_del_campo

lv_indice_campo = 3. "Cambiar por la posición deseada.

LOOP AT <table> INTO <wa>.
ASSIGN COMPONENT lv_indice_campo OF STRUCTURE <wa> TO <field>.
MOVE <field> TO lv_valor_campo.
ENDLOOP.

En el ejemplo de arriba se accede al tercer campo del registro que se esté tratando actualmente en el interior del bucle de tratamiento de datos. Es posible acceder a cualquier otro campo cambiando el índice, e incluso generalizarlo para que se acceda a todos los campos de un registro.

En ambos casos el programador será el encargado de controlar los errores que se puedan dar durante el proceso, siendo los más habituales:

1. Que el nombre del campo no exista y por lo tanto no se asigne nada al FIELD-SYMBOL <field>
2. Que el registro no tenga tantos campos como el número que se le pase al índice de acceso y por lo tanto no se asigne nada al FIELD-SYMBOL <field>.

Es posible, mediante la sentencia CHECK <symbol> IS ASSIGNED. comprobar que el FIELD-SYMBOL se encuentra asignado.

*Subrutina de lectura de descripciones de valores de un dominio
FORM recuperar_descripciones TABLES t_domain_values STRUCTURE dd07v USING p_dominio.

REFRESH: t_domain_values.


CALL FUNCTION 'RM_DOMAIN_VALUES_GET'
EXPORTING
i_name = p_dominio "Dominio
i_langu = sy-langu
i_read_texts = c_marca "Recupera descripción
IMPORTING
e_domain_values = t_domain_values
EXCEPTIONS
illegal_input = 1
others = 2.


IF sy-subrc <> 0.
REFRESH: t_domain_values.
ENDIF.

ENDFORM. " recuperar_descripciones

La función estándar  'RM_DOMAIN_VALUES_GET' aporta la funcionalidad deseada para este caso mediante el parámetro i_read_texts que deberá tener un valor 'X' representado por la constante c_marca declarada de una de las siguientes formas:

CONSTANTS: c_marca TYPE xfeld VALUE 'X' .

CONSTANTS: c_marca TYPE c VALUE 'X'.

El resultado de la lectura de los valores se almacenará en una tabla con estructura estándar dd07v que contiene un binomio [clave, valor] dónde la clave será uno de los posibles valores que puede adoptar el dominio internamente y el valor será la descripción que, en este caso, es lo que se pretende recuperar.

El objetivo principal de usar este FORM es mostrar las descripciones de los valores posibles en una lista desplegable, en un table control o un listado ALV, cosa que, de cara al usuario, es más comprensible que ver códigos internos.

• Implementar soluciones a medida dentro de SAP R/3 y SAP Retail
• Mantenimiento de soluciones implementadas con anterioridad

Julio 2005 – Agosto 2005
Empresa – Diario El Correo
Puesto – Técnico de sistemas
Responsabilidades

• Diagnóstico y reparación de ordenadores PC y Mac
• Mantenimiento de redes y servidores

Julio 2004
Empresa – Diario El Correo
Puesto – Técnico de sistemas
Responsabilidades

• Diagnóstico y reparación de ordenadores PC y Mac
• Mantenimiento de redes y servidores

Febrero 2003 – Junio 2005
Empresa – Universidad de Deusto
Puesto – Becario de desarrollo de aplicaciones Web
Responsabilidades

• Creación de soluciones a medida ASP y ASP.NET
• Mantenimiento de aplicaciones legacy ASP.
• Migración de aplicaciones ASP a ASP.NET.

• Creación de interfases de comunicación entre SAP y sistema gestor de almacenes del cliente
• Creación de programas de carga para migración de datos de cliente.

Febrero 2009 – Mayo 2009
Mantenimiento SAP Retail – Accenture SAP Solutions
Lenguaje de programación: ABAP IV

• Corrección de  incidencias en programas existentes
• Desarrollo e implementación de mejoras a petición del cliente

Enero 2008 – Febrero 2009
Implantación SAP Retail – Accenture SAP Solutions
Lenguaje de programación: ABAP IV

• Implementación de soluciones a medida dentro de SAP Retail
• Corrección de incidencias en programas existentes
• Desarrollo e implementación de mejoras a petición del cliente

Enero 2007 – Octubre 2007
Aventura de acción 3D: Fear No More – Universitat Pompeu Fabra
Lenguaje de programación: C++

• Diseño
• Programación de la inteligencia artificial.
• Programación de un sistema de pistas para el modo de dificultad inferior.

Enero 2006 – Septiembre 2006
Motor y editor de protocolos de red – Universidad de Deusto
Lenguaje de programación: JAVA

• Uso y modificación de librería de serialización existente.
• Diseño e implementación de aplicación gráfica de edición de protocolos de red
• Diseño e implementación de una máquina de estados finitos (FSM) para su uso como motor de red basada en teoría de máquinas de estados
• Diseño e implementación de sistemas de comunicación síncronos y asíncronos.
• Documentación del proyecto

Año 2005
Juego de baile: Dance Dance Revolution – Universidad de Deusto
Lenguaje de programación: Action Script

• Diseño e implementación de los menús usando tecnología Flash
• Documentación del proyecto
• Pruebas e integración

Estudio de sistemas de ficheros encriptados – Universidad de Deusto

• Investigación y selección de tres sistemas para las plataformas más utilizadas: Windows, Mac y Linux
• Instalación y prueba de los sistemas de ficheros elegidos para el estudio
• Documentación y evaluación de los datos obtenidos

Año 2003
Juego de acción 3D: El Señor de la Saca – Universidad de Deusto
Tecnologías: Alias Wavefront Maya 4, 3D Studio Max 6, Macromedia Director

• Diseño mecánicas, escenarios y enemigos
• Texturización de objetos 3D
• Conversión de mallas 3D e integración de escenarios
• Producción, monitorización de recursos y planificación
• Documentación
• Presentación

Agenda  personal – Universidad de Deusto
Lenguaje de programación: Visual Basic .NET

• Diseño e implementación
• Pruebas e integración
• Documentación

Página web de contactos – Universidad de Deusto
Lenguaje de programación: ASP .NET

• Diseño e implementación
• Pruebas e integración
• Documentación

Año 2002
Servidor multicomando – Universidad de Deusto
Lenguaje de programación: ANSI C
Tecnologías: Sockets

• Diseño e implementación del servidor
• Diseño de un sistema de opciones por archivo de configuración
• Servidor capaz de aceptar múltiples comandos
• Documentación

Septiembre 2006
Ingeniería en informática – Universidad de Deusto

Septiembre 2004
Ingeniería técnica en informática de gestión – Universidad de Deusto.

• Duración: 180 horas
• Impartido por: Accenture SAP Solutions

Año 2005
Seminario de Macromedia Director y Flash

• Duración: 45 horas
• Impartido por:  Universidad de Deusto

Seminario de seguridad en redes de información

• Duración: 45 horas
• Impartido por: Universidad de Deusto

Laboratorio de sistemas distribuidos

• Duración: 60 horas
• Impartido por: Universidad de Deusto

Año 2003
Seminario de aplicaciones Web con .NET

• Duración: 60 horas
• Impartido por: Universidad de Deusto

Seminario de aplicaciones Windows con .NET

• Duración: 60 horas
• Impartido por: Universidad de Deusto

Año 2002
Seminario de Linux

• Duración: 60 horas
• Impartido por: Universidad de Deusto

• Formación autodidacta en Objective C 2.0 y programación para iPhone.
• iPhone Developer registrado con licencia para publicar aplicaciones gratuítas en la App Store.

Producción de videojuegos

• Gestión de assets
• Planificación y entrega de proyectos