MODUL POOL. Definición. Objetos que lo integran y Metodología de tratamiento.

1. INTRODUCCION. Definimos el Workbench como un entorno gráfico de programación, que contiene todas las herramientas necesarias para crear y probar objetos de desarrollo. El propósito de este manual es presentar aquellas que tienen una función específica en el proceso de desarrollo de una transacción, así como explicar el concepto y funcionalidad de todos los objetos que intervienen en ella.

1.1 TIPOS DE PROGRAMAS.

1.1.1 REPORTS.

Desarrollo de listados, informes u otro tipo de aplicativos que no precisen respuesta inmediata del usuario. La finalidad de un report es leer datos de la base de datos y listarlos en una pantalla. Consta solamente de dos pantallas: La primera pantalla, selection screen, contiene campos input que permiten al usuario entrar criterios de selección para el report. Es opcional. La segunda, contiene la lista de datos.

1.1.2 TRANSACCIONES.

Desarrollo de aplicaciones interactivas con pantallas on line. Son más flexibles que los reports, y también un nivel de programación mucho más complejo. Pueden contener cualquier número de pantallas, y la secuencia de pantallas puede cambiarse dinámicamente en tiempo de ejecución. En cada pantalla, podemos tener campos input, campos output, botones y más de una área de scroll.

1.1.2.1 MODULE POOL. (Definición)

Es un término que describe el conjunto de entidades ABAP/4 que subyacen en una transacción. .

2. COMO CREAR UN MODULE POOL. La creación de un module pool es un proceso complejo, dado que, como ya se ha mencionado anteriormente, consta de varios objetos. Para ello es necesario un estudio exhaustivo de las herramientas del Workbench, ya que cada una de ellas desempeña una función específica en la construcción de una transacción.

2.1 WORKBENCH.

2.1.1 HERRAMIENTAS.

Dictionary: Almacena una amplia definición de los datos del sistema. Cuando se crea una nueva definición, el Diccionario realiza todos los procesos necesarios para que ello sea posible. Editor ABAP/4: Se utiliza para crear código o modificar uno ya existente. Verifica la sintaxis, y permite generar, ejecutar y debugar nuestros programas. Biblioteca de funciones: Es un repositorio de rutinas. Cuando creamos una rutina nueva, la Biblioteca de funciones es quien realiza todos los procesos necesarios para crearla. Screen painter y Menu painter: Útiles para diseñar los intefaces gráficos de usuario (GUI, Grafical User Interface) para nuestro programa. El Screen painter sirve para añadir campos, pulsadores y otros elementos de pantalla. El Menu painter es útil para crear menus que rodean la pantalla. Object Browser: Dado que un programa se compone de diferentes elementos y que a menudo no es fácil ver las relaciones existentes entre ellos, el Object Browser es una magnífica herramienta para ver de una forma rápida y sencilla, todos los objetos de desarrollo que componen nuestra aplicación y las relaciones existentes entre ellos.

2.2 TECNICA RECOMENDADA. (Object Browser). Podemos crear una aplicación entera utilizando el Object Browser sin necesidad de llamar directamente otras herramientas. De hecho, el método recomendado para crear una aplicación es desde el Object Browser, porque de este modo, podemos ver en todo momento qué estamos construyendo. Pulsando el botón Object Browser, aparece la siguiente pantalla:

2.2.1 ACCIONES A REALIZAR.

2.2.1.1 CLASE DE DESARROLLO.

Elegir la clase de desarrollo donde queremos crear nuestro programa y pulsar el botón Visualizar. Nota: En este manual, todos los objetos se crearán en la clase $TMP. Aparece la siguiente pantalla:

2.2.1.2 PROGRAMAS.

Marcar el tipo de objeto Programas y pulsar el icono Crear. Aparecerá la siguiente pantalla de diálogo:

Hay que asegurarse de que el nombre de programa es correcto y que el flag Include TOP está activado.

2.2.1.2.1 CONVENCIONES DE NOMENCLATURA.

La longitud de los nombre de programas debe oscilar entre 2 y 8 caracteres, y debe empezar por Y o Z. SAP reserva las letras de la A a la X para sus propios programas. Se recomienda que los siguientes 3 caracteres sean un identificador del programa, tales como las iniciales del programador, o inicial del nombre del proyecto e iniciales del módulo funcional. Ej: YRREIN01. Los programas de diálogo o module pool, siguen una convención particular:

Los cuatro primeros caracteres deben ser SAPM. El quinto carácter debe ser Y o Z. Los tres últimos caracteres deben ser caracteres válidos.

Así, se distingue un module pool de un report . Mientras que el nombre de un report será Yxxxxxxx / Zxxxxxxxx, el nombre de un module pool será SAPMYxxx o SAPMZxxx. Lista de caracteres no permitidos.

Carácter Descripción . Punto , Coma

Blancos ( ) Paréntesis ‘ Comilla “ Doble comilla = Signo Igual * Asterisco _ Subrayado % Tanto por ciento

Ää Öö Üü Letras con dièresis

2.2.1.2.2 INCLUDE TOP.

El sistema genera por defecto el include TOP, que es donde se guardarán las declaraciones de todos los datos globales del sistema ( Tablas de diccionario, tablas internas, variables, constantes…). El nombre del include será por convención : MYxxxTOP o MZxxxTOP, donde xxx son los tres últimos caracteres del nombre del programa. El segungo carácter Y o Z, dependerá del quinto carácter elegido en el nombre del programa. En nuestro ejemplo, para el programa SAPMY001 el include TOP se llamará MY001TOP.

Al pulsar Intro, se displayará automáticamente la pantalla de atributos del programa.

2.2.1.2.3 ATRIBUTOS DEL PROGRAMA.

Atributos obligatorios: Título: Descripción breve del programa. Tipo: M (Module Pool) Aplicación: En nuestro caso, se ha elegido Y (Datos cliente central). Para ver los demás posibles valores, pulsar F4 sobre el campo Aplicación.

Atributos opcionales: Son los demás campos de la pantalla. Se recomienda tener el flag Calc.coma fija activado, sobre todo si en el programa se realizan operaciones de cálculo. El atributo Bloc.Editor es útil si queremos que el fuente no sea modificado. Sólo puede desactivarlo el propio creador del programa. Al grabar los atributos, el sistema genera automáticamente el programa y el include Top. Para verificar, que el proceso ha concluído con éxito, se recomienda utilizar el Object Browser, visualizar Programas, y ver que aparece nuestro programa en la lista.

Una vez hemos comprobado que el programa aparece en la lista, situamos el cursor sobre el mismo, y haciendo doble click, aparecerá una pantalla donde veremos la lista de objetos del programa. En este momento, sólo tenemos el tipo de objeto Include donde aparece el include Top generado.

2.2.1.2.4 OTROS INCLUDES. ( Módulos PBO, Módulos PAI, Forms o rutinas).

En un Module Pool, las pantallas o dynpros tienen un papel primordial. Como se verá más adelante, es recomendable agrupar los procesos Before Output ( PBO, procesos que se ejecutan antes de presentar una pantalla) y los procesos After Input ( PAI, procesos que se ejecutan una vez se ha presentado la pantalla), en includes independientes. Asimismo también se aconseja crear un include que contenga todos los forms o subrutinas que intervengan en el programa. Aunque no es obligatorio proceder de este modo, sí es altamente recomendable, pues desde el Object Browser, será muy fácil identificar y localizar un determinado proceso. Para crearlos, desde esta misma pantalla, marcar Includes y pulsar el icono Crear. Aparecerá la siguiente pantalla:

2.2.1.2.4.1 CONVENCIONES DE NOMENCLATURA.

Include Módulos PBO: El nombre del include será : MYxxxO01 o MZxxxO01, dependiendo del quinto carácter utilizado en el nombre del programa. Xxx serán los tres últimos caracteres que figuren en el nombre del programa. Seguidamente O01 identifica con la O de output, que el include agrupará todos los procesos PBO. En nuestro ejemplo el nombre del include será : MY001O01. Al pulsar Intro, aparece la pantalla de atributos que ya conocemos, especificando que el tipo de programa es I (Include). Include Módulos PAI: El nombre del include será : MYxxxI01 o MZxxxI01, dependiendo del quinto carácter utilizado en el nombre del programa. Xxx serán los tres últimos caracteres que figuren en el nombre del programa. Seguidamente I01 identifica con la I de input, que el include agrupará todos los procesos PAI. En nuestro ejemplo el nombre del include será : MY001I01. Al pulsar Intro, aparece la pantalla de atributos que ya conocemos, especificando que el tipo de programa es I (Include). Include Forms:

El nombre del include será : MYxxxF01 o MZxxxF01, dependiendo del quinto carácter utilizado en el nombre del programa. Xxx serán los tres últimos caracteres que figuren en el nombre del programa. Seguidamente F01 identifica con la F de forms, que el include agrupará todos los forms que aparecen en el programa. En nuestro ejemplo el nombre del include será : MY001F01. Al pulsar Intro, aparece la pantalla de atributos que ya conocemos, especificando que el tipo de programa es I (Include). Para verificar que la acción ha sido correcta, volver al Object Browser y desplegar el tipo de objetos Include de nuestro programa. Verificar que aparecen en la lista.

2.2.1.2.5 VENTAJAS DE LA MODULARIZACION.

Tal como se ha explicado anteriormente, es recomendable crear esta estructura porque así, es más fácil localizar un proceso en un programa y asociarlo inmediatamente a una funcionalidad determinada. Al editar el programa, o la lógica de proceso de una pantalla, el sistema crea automáticamente los procesos que intervienen, en el include que corresponda, ya sea un form, un proceso PBO o un proceso PAI. De este modo, en el programa principal sólo aparecen los includes creados, siendo necesario, visualizar cada uno de ellos para ver el código de un determinado proceso.

Atención: Este código del programa principal se ha generado automáticamente sólo por el hecho de haber creado los includes. Ver que sólo aparece operativo el creado automáticamente por el sistema. Tener la precaución de, llegados a este punto, desasteriscar los que acabamos de crear. Sólo así funcionará la modularización. Nota: Podemos incluir en el fuente del programa principal tantas líneas Include como includes utilice el programa. Pueden ser de nueva creación o includes ya existentes en otros programas. Ejemplo: INCLUDE MY002F01. “ Include de forms del programa SAPMY002.

2.2.1.3 DYNPROS.

Un dynpro (dynamic process) es el conjunto de una pantalla más su lógica de proceso.

2.2.1.3.1 PANTALLA.

Una pantalla es la organización de los elementos gráficos que aparecen en una ventana.

2.2.1.3.2 LOGICA DE PROCESO.

Es el conjunto de procesos que gobiernan el comportamiento del programa, antes y después de la presentación de la pantalla. (Módulos PBO, Módulos PAI).

2.2.1.4 COMO CREAR UN DYNPRO.

En este capítulo, sólo se describirá el proceso de creación propiamente dicho. El diseño de la pantalla y el desarrollo de la lógica de proceso se explicarán detalladamente en un capítulo posterior.

Marcar desde el Object Browser Tipos de objetos de programa y pulsar el icono Crear. Aparecerá la siguiente ventana de diálogo:

Ver que el dynpro que se va a crear, se asocia a nuestro programa SAPMY001.

2.2.1.4.1 CONVENCIONES DE NOMENCLATURA.

Los dynpro se identifican con tres dígitos numéricos distintos de 000. Normalmente, los dynpro de programas standard se identifican por 9*, es decir 900, 910… Los dynpro de programas desarrollados a medida normalmente se identifican por 100, 200…etc. Normalmente, un module pool consta de dos dynpro (el primero de selección y el segundo, para el tratamiento de los datos), aunque puede tener más. Se suele utilizar la convención 100 para el dynpro de selección y 200 para el de tratamiento.

2.2.1.4.2 ATRIBUTOS DEL DYNPRO.

Al pulsar el icono Crear aparecerá la pantalla de atributos:

Por defecto aparece cumplimentado el campo Dynpro siguiente con el mismo número de dynpro que estamos creando. Esto puede ser útil si queremos gobernar desde el programa el comportamiento del dynpro al pulsar return una vez presentada la pantalla. Si queremos que el control pase automáticamente al dynpro siguiente sin tener que programarlo, podemos indicar en este campo 200 p.e. La siguiente acción a realizar es Grabar y Generar. Para verificar que el dynpro ha sido creado correctamente, ver si aparece en la lista de objetos de nuestro programa:

Se repetirá el proceso tantas veces como dynpros queramos utilizar.

2.2.1.5 GUI STATUS.

El Status define la combinación de barras de menú, listas de menú, teclas de función y funciones válidas en un interface. Por ejemplo, una aplicación puede tener dos status : Visualización / Actualización. En la barra de menús se definen las funciones disponibles para el usuario. En la lista de menú se especifican las acciones de un menú específico.

2.2.1.5.1 COMO CREAR UN STATUS.

Del mismo modo, que en el caso de creación de dynpros, desde el Object Browser, marcar Tipos de Objetos del programa y pulsar el icono Crear. Aparece la misma ventana de diálogo que en el caso de creación de pantallas, pero ahora habrá que especificar que el objeto que se desea crear es un Status.

Al pulsar el icono Crear, aparece la siguiente pantalla de diálogo:

Especificamos que el Status se asociará a un dynpro, para que el sistema genere por defecto las características propias de un status de pantalla. Las siguientes acciones a realizar son Grabar y Generar.

2.2.1.5.2 CONVENCIONES DE NOMENCLATURA.

En principio, no hay ninguna convención establecida. Sin embargo, es aconsejable nombrar el Status con el mismo nombre de la pantalla a la que se va a asociar. Nota: Ver que un Status no es un objeto de una pantalla, sino que es un objeto de un programa.

2.2.1.6 TITULOS.

Un título es la descripción que aparece en la parte superior del dynpro. Normalmente, se asocia el título a un status, a pesar de que un título no es un objeto del status, sino que es un objeto del programa.

2.2.1.6.1 COMO CREAR UN TITULO.

Análogamente a la creación de los objetos antes definidos, desde el Object Browser marcamos Objetos del Programa y pulsamos el icono Crear. Aparece la ventana de diálogo donde especificamos que queremos crear un Título, y al pulsar Intro, aparecerá la siguiente pantalla:

Como siempre, para verificar que el título se ha creado correctamente, consultamos el Object Browser.

2.2.1.7 TRANSACCIONES.

Normalmente un module pool puede ser llamado desde una o varias transacciones.

2.2.1.7.1 COMO CREAR UNA TRANSACCION.

Análogamente a la creación de los objetos antes definidos, desde el Object Browser marcamos Objetos del Programa y pulsamos el icono Crear. Aparece la ventana de diálogo donde especificamos que queremos crear una Transacción, y al pulsar Intro, aparecerá una ventana donde habrá que especificar que el tipo de transacción ha de ser de diálogo. Una vez hecho esto:

Es en esta pantalla, donde se define el comportamiento de la transacción. En el campo Programa, se especifica el nombre del programa que queremos que se ejecute cuando se lanza la transacción. En el campo Dynpro, especificamos cuál es la pantalla del programa que queremos que se presente. En nuestro ejemplo, la transacción Y001 ejecutará el programa SAPMY001 presentando el dynpro 100 de dicho programa.

2.2.1.7.2 CONVENCIONES DE NOMENCLATURA.

Los códigos de transacción constan de cuatro caracteres y deben empezar por Y o Z. En general, se recomienda la siguiente convención: Acción Codificación Alta Yxx1, Zxx1 Modificación Yxx2, Zxx2 Borrado Yxx3, Zxx3 Visualización Yxx4, Zxx4

2.3 SUMARIO. De este modo, ya hemos construído el esqueleto de un module pool, con todos los objetos necesarios para su funcionamiento. El Object Browser nos lo muestra:

I-Y001

MODUL POOL. Definición. Objetos que lo integran y Metodología de tratamiento. 1. INTRODUCCION.................................................................................................................................. 1

1.1 TIPOS DE PROGRAMAS................................................................................................................ 1 1.1.1 REPORTS. ................................................................................................................................. 1 1.1.2 TRANSACCIONES..................................................................................................................... 1

1.1.2.1 MODULE POOL. (Definición).......................................................................................................... 1

2. COMO CREAR UN MODULE POOL................................................................................................ 2

2.1 WORKBENCH. ................................................................................................................................ 2 2.1.1 HERRAMIENTAS. ..................................................................................................................... 3

2.2 TECNICA RECOMENDADA. (OBJECT BROWSER). ....................................................................... 4 2.2.1 ACCIONES A REALIZAR.......................................................................................................... 4

2.2.1.1 CLASE DE DESARROLLO.............................................................................................................. 4 2.2.1.2 PROGRAMAS. .................................................................................................................................. 5

2.2.1.2.1 CONVENCIONES DE NOMENCLATURA. ........................................................................... 5 2.2.1.2.2 INCLUDE TOP.......................................................................................................................... 6 2.2.1.2.3 ATRIBUTOS DEL PROGRAMA. ............................................................................................ 7 2.2.1.2.4 OTROS INCLUDES. ( Módulos PBO, Módulos PAI, Forms o rutinas). ................................. 9

2.2.1.2.4.1 CONVENCIONES DE NOMENCLATURA. ................................................................. 10 2.2.1.2.5 VENTAJAS DE LA MODULARIZACION............................................................................ 11

2.2.1.3 DYNPROS. ...................................................................................................................................... 12 2.2.1.3.1 PANTALLA. ........................................................................................................................... 12 2.2.1.3.2 LOGICA DE PROCESO. ........................................................................................................ 13

2.2.1.4 COMO CREAR UN DYNPRO........................................................................................................ 13 2.2.1.4.1 CONVENCIONES DE NOMENCLATURA. ......................................................................... 14 2.2.1.4.2 ATRIBUTOS DEL DYNPRO. ................................................................................................ 15

2.2.1.5 GUI STATUS.................................................................................................................................. 16 2.2.1.5.1 COMO CREAR UN STATUS................................................................................................. 16 2.2.1.5.2 CONVENCIONES DE NOMENCLATURA. ......................................................................... 18

2.2.1.6 TITULOS. ........................................................................................................................................ 18 2.2.1.6.1 COMO CREAR UN TITULO. ................................................................................................ 18

2.2.1.7 TRANSACCIONES......................................................................................................................... 19 2.2.1.7.1 COMO CREAR UNA TRANSACCION................................................................................. 19 2.2.1.7.2 CONVENCIONES DE NOMENCLATURA. ......................................................................... 20

2.3 SUMARIO....................................................................................................................................... 20