Desarrollo en SAP de herramientas para el módulo laboratorio

1 2 3 ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA INFORMÁTICA GRADO EN INGENIERÍA INFORMÁTICA DESARROLLO EN SAP DE HERRAMIENTAS PARA EL MÓDULO LABORATORIO SAP DEVELOPMENT OF TOOLS FOR THE LABORATORY MODULE Realizado por Adrián Sánchez Fernández Tutorizado por José María Álvarez Palomo Eusebio Hernández Villalobos Departamento Lenguajes y Ciencias de la Computación UNIVERSIDAD DE MÁLAGA MÁLAGA, Diciembre de 2016 Fecha defensa: El Secretario del Tribunal 4 5 Resumen: En la actualidad, los sistemas de planificación de recursos empresariales, también conocidos como sistemas ERP, son herramientas muy usadas en la mayoría de los negocios, facilitando el control del proceso empresarial. Dos de las grandes características de los ERP es que son modulares y configurables, permitiendo instalar aquellos módulos necesarios para la empresa y poder configurarlos conforme surjan necesidades de hacerlo. SAP es una compañía alemana cuyo producto estrella es su ERP, compatible con la gran mayoría de sistemas operativos, bases de datos, aplicaciones y componentes de hardware de casi cualquier proveedor. El desarrollo de nuevas herramientas se realiza mediante código ABAP IV, también propiedad de SAP. En este trabajo, se va a desarrollar la creación de nuevas herramientas para dicho ERP y su implantación en el sistema final, gestionando todas las fases que existen en cualquier desarrollo software. Más concretamente, se crearán herramientas que permitirán guardar una serie de datos en el sistema, realizar cálculos y generar informe de los resultados obtenidos. Palabras clave: Planificación de recursos empresariales, ERP, Empresa, SAP, SAP NetWeaver, ABAP, Control de Materiales, Normas UNE. Abstract: Nowadays, Enterprise Resource Planning Systems, more known as ERP Systems, are tools widely used in most business, making business process control easier. The two most important characteristics of ERP Systems are they are modular and configurable, allowing companies to install only those modules required by the company and they can be set when they are needed. SAP is a German company whose best-known product is its ERP, which is compatible with most of operating systems, databases, applications and hardware from any supplier. The development of new tools within SAP System is done using ABAP code, also owned by SAP. In this project, new tools for this ERP are going to be developed and implemented in it, managing all phases which exist in any software development. More specifically, we are going to develop tools which will save data in the system, perform calculations and generate reports about the results obtained. Keywords: Enterprise Resource Planning, ERP, Company, SAP, SAP NetWeaver, ABAP, Materials Control, UNE Standards. 6 7 Índice 1. Introducción ................................................................................................................................ 9 1.1 Entorno del Trabajo Fin de Grado ................................................................................. 9 1.1.1 Finalidad ........................................................................................................................ 9 1.1.2 Ámbito del Trabajo ..................................................................................................... 10 1.2 Metodología ...................................................................................................................... 13 1.3 Entorno de desarrollo ..................................................................................................... 14 1.3.1 SAP .............................................................................................................................. 14 1.3.2 SAP Business Suite ................................................................................................... 14 1.3.3 SAP NetWeaver ......................................................................................................... 15 1.3.4 SAP ERP ..................................................................................................................... 16 1.3.5 ABAP IV ...................................................................................................................... 18 1.3.6 Otras herramientas .................................................................................................... 22 1.4 Organización del documento ........................................................................................ 23 2. Preparación del trabajo .......................................................................................................... 25 2.1 Elección de la temática del TFG ................................................................................... 25 2.2 Recopilación de documentación ................................................................................. 25 3. Análisis y Diseño ..................................................................................................................... 27 3.1 Análisis de los Requisitos ............................................................................................. 28 3.2 Casos de Uso.................................................................................................................... 30 3.3 Diseño ................................................................................................................................ 36 3.3.1 Entrada de Muestras ................................................................................................. 36 3.3.2 Entrada de Resultados .............................................................................................. 37 3.3.3 Generación de Informes............................................................................................ 48 3.4 Modelo de Datos .............................................................................................................. 49 4. Implementación ....................................................................................................................... 63 4.1 Diccionario de Datos ...................................................................................................... 65 4.2 Entrada de Muestras ....................................................................................................... 66 4.3 Entrada de Resultados ................................................................................................... 70 4.4 Creación de Informes ..................................................................................................... 77 5. Pruebas e Implantación ......................................................................................................... 87 5.1 Pruebas .............................................................................................................................. 89 5.2 Implantación ..................................................................................................................... 91 6. Cambios ..................................................................................................................................... 93 8 7. Conclusiones ............................................................................................................................ 99 Bibliografía ...................................................................................................................................... 101 Tabla de Ilustraciones .................................................................................................................. 103 9 1. Introducción 1.1 Entorno del Trabajo Fin de Grado 1.1.1 Finalidad La idea de este Trabajo Fin de Grado es aprovechar el funcionamiento de un Sistema de Planificación de Recursos Empresariales (más conocido como ERP: Enterprise Resource Planning) para unir 2 departamentos totalmente diferentes de una empresa, de forma que puedan colaborar entre ellos para obtener un beneficio común. Un ERP es un sistema de gestión de información que automatiza mucha de las prácticas de negocio asociadas con los aspectos operativos o productivos de una empresa, tales como producción, ventas, compras, logística, gestión de proyectos… Los objetivos principales de los sistemas ERP son:  Optimización de los procesos empresariales.  Acceso a la información  Posibilidad de compartir información entre todos los componentes de la organización  Eliminación de datos y operaciones innecesarias de reingeniería. El propósito fundamental de un ERP es otorgar apoyo a los clientes del negocio, tiempos rápidos de respuesta a sus problemas, así como un eficiente manejo de información que permita la toma oportuna de decisiones y disminución de los costos totales de la operación. Ilustración 1 - Elementos de un ERP 16 Fue lanzado como un movimiento estratégico de SAP que plantea a las empresas ejecutar todas sus aplicaciones empresariales en una única plataforma integrada con la más firme infraestructura. Esta solución incorpora una gran flexibilidad, una mejor integración con las aplicaciones y construcción en estándares para asegurar la futura interoperación. Este lanzamiento en suma es una parte del plan de SAP de transformarse en una herramienta más abierta y orientada a servicios adecuados a las necesidades del mercado. 1.3.4 SAP ERP En la actualidad, y con el fin de afrontar las necesidades que surgen en el seno de las empresas para lograr una productividad más eficaz, existen una gran cantidad de alternativas de software que se aplica a toda la cadena que recorre un producto. Una de las más utilizadas, y en las que se basan otros sistemas, es el producto ERP de SAP, denominado SAP R/3. El SAP R/3 es un sistema ERP que ha sido diseñado en base a una plataforma que ofrece una gran versatilidad de programación, facilidad de uso, y precisión en el manejo total de los datos recolectados. Su nombre se remite a dos factores importantes que caracterizan a dicho software. En principio, la R se refiere al procesamiento en tiempo real, y el número 3 a los tres niveles de la arquitectura de procesos con los que trabaja: bases de datos, servidor de aplicaciones y cliente. Ilustración 8 - SAP R/3 17 Mediante este interesante sistema de gestión es posible realizar un control exhaustivo de todos los procesos y operaciones que se realizan dentro de una compañía, almacenando la información que puede ser utilizada por cualquier sector de la organización. El sistema R/3 está diseñado en módulos claramente diferenciados, que responden a las necesidades propias de cada una de las áreas de una empresa. A su vez, cada uno de los módulos que conforman este sistema posee diferentes submódulos que interactúan entre sí, ofreciendo de esta manera una colección precisa y diferenciada de la información referente a los productos fabricados por la compañía, desde la recepción de las materias primas, pasando por la manufactura y empaquetado de los artículos, hasta la entrega del producto terminado en el punto de venta. Este sistema no sólo es útil para los casos en que se requiera una solución estándar, sino también para aquellas empresas que necesiten un sistema a medida; esto es posible gracias a las poderosas herramientas de desarrollo que se proveen, mediante el lenguaje de programación ABAP/4, que ha sido creado en base a las necesidades comerciales que existen en la actualidad. Por lo tanto, la empresa puede crear o modificar los módulos existentes para ajustarlos a sus necesidades. El sistema R/3 permite una total personalización, incluyendo la posibilidad de construir interfaces propias, creadas en base a los requerimientos de cada sector, ofreciendo la posibilidad de trabajar con un sistema del tipo abierto, en el que la información almacenada se encuentra disponible en cualquier momento y para todas las áreas de la empresa. Ilustración 9 - Módulos SAP R/3 18 De esta manera, se reducen los costos, se mejora la productividad, y se optimizan los procesos de transacciones, entre otras grandes ventajas. En base al principio de cliente/servidor, el sistema R/3 funciona a través de un software que trabaja a varios niveles, permitiendo una interacción constante entre los clientes y los servidores, gracias a la posibilidad de crear la cantidad de módulos que sean necesarios. Por otra parte, al tratarse de un sistema de tipo abierto, no sólo facilita los procesos de transacciones y el manejo de la información, sino que además permite un eficaz control de los datos y las comunicaciones entre los clientes y los servidores. SAP R/3 funciona con el protocolo TCP/IP para comunicaciones en red, soporta redes del tipo SQL, utiliza interfaz de comunicación CPI-C para las comunicaciones realizadas entre diferentes programas por intermedio de sistemas múltiples, trabaja bajo las normas ODBC para la conectividad de la base de datos abierta, incluye la arquitectura RPC, dentro del lenguaje ABAP/4 como interfaz de programación abierta, funciona a través del estándar denominado OLE/DDE para llevar a cabo las integraciones de las aplicaciones de las computadoras con el sistema, y responde a las normas de comunicaciones externas X.400/X.500, MAPI. En la actualidad, el sistema SAP R/3 es totalmente compatible con los sistemas operativos Windows 95, Windows 98, Windows NT, Macintosh, Red Hat de Linux, IBM OS/400, IBM S/390, OS/2, Citrix, HP-UX, AIX, MPE/iX y Open VMS. Además, posee soporte para bases de datos del tipo Microsoft SQL Server, Oracle, IBM DB/2, Adabas, Informix y Sybase ASE. Otra característica es que la implementación de programas y funciones se puede realizar en un lenguaje orientado a objetos (por ejemplo: Java) o, siendo más habitual este modo, realizarlo con el propio lenguaje de cuarta generación del sistema, ABAP, a través del entorno de programación que incluye el Sistema: ABAP Workbench. 1.3.5 ABAP IV ABAP (Advanced Business Application Programming) es un lenguaje de cuarta generación, propiedad de SAP, que se utiliza para programar la mayoría de sus productos (R/3, mySAP Business suite...). ABAP fue desarrollado por SAP como lenguaje de informes para SAP R/2, en los años 80, una plataforma que permitía a las grandes corporaciones construir aplicaciones de negocios para gestión de materiales y finanzas. En sus inicios, ABAP estuvo basado en COBOL, ya que este era el paradigma de lenguaje orientado a negocios; además incluía el concepto de Bases de datos lógicas, que suministraba un alto nivel de abstracción para el acceso a bases de datos. ABAP fue pensado como un lenguaje de programación para que los usuarios finales pudieran manipular la información, pero el 4GL (Lenguaje de cuarta Generación) se fue volviendo demasiado complicado para usuarios normales, por lo que se requieren programadores con una cierta experiencia en esta tecnología para realizar desarrollos. ABAP se mantuvo como el lenguaje de desarrollo para la siguiente versión clienteservidor de SAP R/3, que fue lanzada al mercado en 1992, en el que casi todo el 19 sistema, menos las llamadas al sistema básicas estaban escritas en ABAP. En 1999, con el lanzamiento de la versión 4.6 de R/3, SAP lanzó una extensión orientada a objetos denominada ABAP Objects, lo que permite la compatibilidad con lenguajes de programación orientados a objetos como Java. La comunicación con bases de datos se realiza a través de una interfaz que transforma las sentencias escritas en Open SQL en el SQL Nativo del correspondiente DBMS. Además, esta interfaz proporciona servicios muy útiles como el buffering en memoria local del servidor de tablas y datos recientes o frecuentemente solicitados. Sintaxis Aunque las sentencias de este lenguaje de programación son similares a las de COBOL, estas cuentan con cierta variedad de opciones, característica que hace que el conjunto total de sentencias sea bastante amplio, pudiendo dividirse en los siguientes seis grupos:  Sentencias Declarativas, usadas para definir tipos y variables.  Sentencias de Modularización, usadas para definir los bloques 3 de proceso.  Sentencias de Control, usadas para establecer el flujo de ejecución del programa en un evento.  Sentencias de Llamadas, usadas para realizar la llamada a otros bloques.  Sentencias Operativas: usadas para modificar el contenido de las variables, incluyendo las sentencias Open SQL y las destinadas para manejo de tablas internas.  Sentencias de Formato, usadas para dar formato a la salida de datos del programa. Anteriormente, se ha hecho mención a las tablas internas; se trata de una de las funcionalidades más prácticas del lenguaje ABAP, y que ofrece mayor potencia a la hora de trabajar con datos. Las tablas internas son variables que permiten almacenar registros en memoria, pudiendo considerar componente en una línea como una columna en una tabla interna. Se tratan de estructuras de datos declaradas durante la implementación del programa para adaptarse a las necesidades del programador, y que permiten el almacenamiento de datos temporalmente en la memoria de trabajo. Su importancia radica en que este almacenamiento permite una mayor velocidad de computación y tratamiento de datos, además de ser unas herramientas muy prácticas para incluir estructuras complejas en un programa. Otra aplicación que se le puede dar a las tablas internas es su utilización como tipos de datos. 3 Un bloque es un código llamado (subrutinas, funciones, métodos, etc.) o código ejecutable ante un evento. 20 Tipos de programas Como en otros lenguajes de programación, un programa ABAP no es simplemente una unidad ejecutable o una biblioteca, sino que proporciona código ejecutable para otros programas no ejecutado independientemente. Por lo tanto, podemos dividir estas dos clases siguiendo criterios de funcionalidad.  Programas Ejecutables, mayoritariamente asociados a transacciones 4 . o Informes (Reports). Los informes siguen un modelo de programación relativamente simple, dónde el usuario introduce una serie de parámetros y el programa los usa para producir un informe en forma de lista interactiva. o Module Pool. Los module pools definen unos patrones más complejos de interacción con el usuario a través de una colección de pantallas, cada una con su propia lógica.  Programas no ejecutables, que funcionan como apoyo o soporte del resto. o INCLUDEs: Usados para modularizar programas muy largos. o Subrutinas: Contiene subrutinas ABAP, trozos de código que se suelen repetir con frecuencia. o Grupos de Funciones: Son librerías de módulos de funciones, visibles desde cualquier programa. o Clases de Objetos: Representan la orientación a objetos junto a las interfaces. o Interfaces: Definiciones de métodos para los cuales las clases deben ofrecer el código. o Tipos: Colección de datos, tipos y constantes. 4 En terminología SAP, se denomina transacción a la ejecución de un programa. Ilustración 10 - Entorno de programación ABAP 21 En ABAP, las pantallas (mencionadas anteriormente) son la interfaz gráfica que comunica el Sistema con el usuario. Cada pantalla cuenta con un “flujo lógico”, el cual se refiere al código implícito de ABAP invocado por las pantallas, formando lo que se denomina ‘DynPro’ (Dynamic Program, Programa Dinámico). Cada pantalla tiene su propio flujo lógico, el cual se divide en:  PBO (Process Before Output), eventos que se producen antes de mostrar la pantalla;  y PAI (Process After Input), eventos que se producen tras una acción del usuario. Un mismo programa puede contar con varios DynPros, permitiéndonos navegar entre las distintas ventanas o recargar los datos de la que nos encontremos, dependiendo de la acción que queramos llevar a cabo. Una transacción en terminología SAP es la ejecución de un programa, ya sea estándar del Sistema o desarrollados con posterioridad. La forma normal de ejecutar código ABAP en el sistema SAP es ingresando un código de transacción. Por ejemplo, SE11 es el código de transacción que llama al Diccionario de Datos. Las Transacciones pueden ser llamadas a través de menús definidos por el sistema, especificados por el usuario o basados en roles. También pueden ser invocados mediante el ingreso del código de transacción directamente en el campo de comandos, el cual está presente en todas las pantallas SAP. Las transacciones también pueden ser invocadas por código mediante las sentencias ABAP “CALL TRANSACTION” y “LEAVE TO TRANSACTION”. ABAP Workench Es el espacio de trabajo para el desarrollo de programas en SAP. No se trata únicamente de un editor de código fuente, sino que cuenta con varias herramientas que complementan la edición de código, como el ‘Screen Painter’ (utilizado para diseñar las pantallas gráficamente), ‘Function Builder’ (utilizado para crear grupos de funciones) o el ‘ABAP Dictionary’ (desde el cual gestionar las tablas, tipos de datos, dominios, ayudas de búsqueda, etc.), entre otras. El diccionario ABAP contiene todos los metadatos acerca del sistema SAP. Está muy ligado con la plataforma de trabajo de ABAP en el que cualquier referencia a los datos se obtiene del diccionario (por ejemplo: tablas, vistas, tipos de datos,…). Los tipos de datos más importantes del diccionario son los siguientes:  Tablas: son contenedores de los datos que existen en la base de datos relacional subyacente.  Índices: proporcionan accesos rápidos a los datos de las tablas para aquellas selecciones usadas con mayor frecuencia.  Vistas: se tratan de tablas virtuales que no contienen ningún dato físicamente, sino que definen un subconjunto de columnas de una o más tablas usando condiciones ‘join’.  Estructuras: son tipos de datos que contienen varios campos. 22  Elementos de datos: proporcionan contenido semántico a una tabla o campo estructurado.  Dominios: definen las características estructurales de los elementos anteriormente mencionados (número de decimales de un tipo numérico, cantidad de caracteres de una cadena,…). Los dominios también pueden proporcionar contenido semántico, proporcionando una posible lista de valores.  Ayudas de búsqueda: proporciona una estrategia de búsqueda avanzada cuando un usuario quiere ver el posible valor que tiene un campo. 1.3.6 Otras herramientas Además de los elementos Software descritos anteriormente, se han usado las siguientes herramientas durante el desarrollo de este Trabajo:  Microsoft Office: Word, Excel y Visio. Estas herramientas han sido usadas para realizar la documentación del Trabajo, elaboración de informes y diagramas y de apoyo a la hora de realizar y comprobar los resultados de los ensayos.  Snagit. Se trata de un programa de captura de pantalla y editor de imágenes, que permite también capturas de video.  Citrix: El acceso a SAP NetWeaver se ha realizado a través de un servidor con el sistema operativo Citrix, lo que permitía un acceso remoto a la herramienta sin necesidad de tenerla instalada en el equipo.  Gliffy: Herramienta on-line para la creación de diagramas de flujo, UML, etc.  Draw.io: otra herramienta on-line para creación de diagramas. Ilustración 11 - Diccionario ABAP 23 1.4 Organización del documento Esta memoria se ha elaborado siguiendo el esquema de desarrollo anteriormente explicado; de esta forma, cada capítulo representará una fase del proceso, diferenciando claramente las distintas etapas y simplificando la compresión de las tareas y procesos realizados en cada una de ellas. El modelo de planificación descrito se asemeja al proceso de desarrollo en cascada, debido a que no se debía comenzar ninguna fase nueva del proyecto hasta que se hubiese finalizado la anterior. Esta decisión fue tomada para minimizar el impacto del nuevo desarrollo en el Sistema. Aunque este modelo pueda parecer bastante rígido y poco favorable a cambios, se ha tenido que adaptar a estos ya que, a lo largo del desarrollo, han surgido nuevos requisitos o mejoras de funcionalidad, llegándose a mezclar tareas de distintas fases en algunos momentos del desarrollo. 1. Introducción: en este capítulo se expone el contexto del trabajo realizado, los objetivos y necesidades que lo han hecho posible y una introducción a las tecnologías usadas para este fin. 2. Preparación del trabajo: en este capítulo se analizan las tareas realizadas al comienzo del proyecto, como la elección de la temática del Trabajo Fin de Grado o el estudio de la documentación necesaria antes de iniciar la elaboración del proyecto. 3. Análisis y Diseño: este capítulo está formado por fases como la recopilación de requisitos, el estudio de casos de usos, una visión global de la estructura del proyecto y una primera propuesta del modelo de datos. 4. Implementación: en este capítulo se explicará el desarrollo realizado y se mostrarán ejemplos del código desarrollado. 5. Pruebas e Implantación: en este capítulo se describen los métodos de testeado y validación que se han utilizado para comprobar el correcto funcionamiento de las aplicaciones, así como los pasos a seguir para implantar finalmente los módulos en el sistema y puedan ser usados por los usuarios. 6. Cambios: en este capítulo se detallan los cambios que han surgido durante el desarrollo y la solución adoptada. 7. Conclusiones: este capítulo, el último de la memoria, servirá de reflexión sobre los resultados obtenidos, tanto desde un punto de vista profesional como personal. 24 25 2. Preparación del trabajo 2.1 Elección de la temática del TFG La elección de este Trabajo Fin de Grado se debió en gran parte a un motivo fundamental: durante la época en la que debía empezar a realizarlo, me encontraba trabajando para una empresa de Control de Calidad de Materiales en calidad de becario. Desde la empresa, surgió la oportunidad de utilizar el trabajo allí desarrollado para la realización del TFG y propusieron este proyecto. El hecho de que esta empresa utilizara las tecnologías SAP descritas en el capítulo anterior fue otra de las razones que influyeron en la decisión, ya que serviría para continuar aprendiendo y profundizando en esta tecnología de SAP, muy demandada en la actualidad. Tras valorar esta opción, el siguiente paso fue encontrar un tutor académico que accediera a la labor de dirigir el Trabajo y confirmar con la Escuela que no existiría ningún problema en cuanto a la normativa del Trabajo. Además, el tutor contaba con experiencia en este tema ya que había dirigido hace unos años el Proyecto Fin de Carrera de un alumno, realizado en la misma empresa y con una temática similar. Tras la obtención de la aprobación de todas las partes, se iniciaron los trámites académicos previos al desarrollo del Trabajo. 2.2 Recopilación de documentación Como se ha explicado en el capítulo anterior, la certificación de calidad de los materiales viene dada a partir de una serie de normas, las normas UNE. Esta empresa, al igual que cualquier otra empresa del sector de Calidad que deseen aplicar esta garantía, deben comprar las normas a una entidad perteneciente al CTN. En este caso, desde Laboratorio se proporcionaron un conjunto de normas distribuidas por AENOR, una de las diez certificadoras más importantes del mundo. Estas normas son la base de las operaciones que se realizan en la Entrada de Resultados, ya que deben ser capaces de calificar la muestra según los datos que se introduzcan en la pantalla; es por ello por lo que su estudio es obligatorio y que fueron usadas continuamente durante las fases de desarrollo y testeado. Además de estas normas, fueron proporcionadas las plantillas de cálculos e informes, así como borradores y ejemplos de informes realizados. Aparte, se debía analizar también los documentos elaborados en proyectos anteriores, de forma que este proyecto se ajustase a los anteriores, tanto en el desarrollo como en la documentación. Con todos estos documentos y los requerimientos impuestos tanto desde el Departamento de Sistemas de Información como Laboratorio, se inició el proceso de análisis y definición previo al desarrollo. 32 o CU2 – Asignar Servicios Ilustración 15 - Diagrama de Secuencia CU2 33 o CU3 – Asignar Plantillas Ilustración 16 - Diagrama de Secuencia CU3 34  Entrada de Resultados o CU4 – Generar resultados Ensayos Ilustración 17 - Diagrama de Secuencia CU4 35  Generación de Informes o CU5 – Generar Informe Ilustración 18 - Diagrama de Secuencia CU5 36 3.3 Diseño Una vez estudiados los requisitos y casos de uso, la siguiente tarea es encontrar una solución visual que de soporte a las especificaciones dadas y que nos permita diseñar el modelo de datos adecuadamente y de forma sencilla. Todas las pantallas de ensayos han sido aprobadas por los técnicos de laboratorio (en calidad de cliente) antes de proceder a la fase de desarrollo, sugiriendo en ocasiones algunos cambios o modificaciones. 3.3.1 Entrada de Muestras A partir de la Entrada de Muestras General, la nueva Entrada de Muestras para Ladrillos debe dar soporte a las nuevas características de este material. En este caso, bastará con añadir un nuevo campo para la Designación del Ladrillo, ya que el resto de campos se encuentran creados en las tablas y tipos existentes en el Diccionario ABAP, y crear o modificar su comportamiento para adaptarse a este nuevo material será una de las tareas de la fase de desarrollo. Ilustración 19 - Nueva Entrada de Muestras 37 3.3.2 Entrada de Resultados Al igual que en la Entrada de Muestras, se nos proporciona una pantalla base sobre la que se creará la nueva funcionalidad; en este caso, la Entrada de Resultados sólo cuenta con los campos que identifican la muestra, datos generales del ensayo (fecha, técnico que lo ha realizado, observaciones, …) y datos de auditoría. Uno de los objetivos principales a la hora de diseñar estas nuevas pantallas fue la de que fuesen lo más similares a las plantillas de Laboratorio, para así facilitar la tarea a los técnicos, ya acostumbrados al diseño de las mismas. Se realizará una pantalla de Entrada de Resultados por cada Ensayo que se realice para Ladrillos. Según las acciones a realizar para llevar a cabo el ensayo, la entrada variará y tendrá un tipo distinto de elementos para la entrada o salida de datos; en algunos bastará con una serie de campos mientras que otros necesitarán de tablas, casillas de verificación o listas despegables. Además, se deberán incluir campos para seleccionar los equipos empleados en las mediciones. A continuación se citan los servicios que se ofertan y los ensayos que se van a realizar junto a una descripción y su diseño correspondiente; en los primeros se indica también como se realiza el ensayo para se pueda apreciar la idea del diseño. La nomenclatura que se ha elegido ha sido la del código de servicio asociado al ensayo, nombre del ensayo y norma o normas asociadas, por lo que se aconseja la lectura de dicha norma en caso de querer ampliar o consultar más información. Ilustración 20 - Entrada de Resultados General 38 1. 14001 – Medición de las dimensiones y comprobación de la forma – UNE 67030:85, UNE 67030:86. Se toman una serie de piezas del material cuya muestra se va a evaluar, de ahora en adelante denominadas como probetas, y se miden la longitud de sus aristas: soga (arista mayor), tizón (arista media) y grueso (arista menor). Como se puede apreciar en la imagen, para la arista denominada Tizón se deben realizar dos mediciones, calculando la media de las mismas; esto se realiza para conocer si existen diferencias en alguna de las dos dimensiones para una misma probeta. Con estas mediciones, y por cada arista, se calcula la media de las mediciones (Valor Medio) y junto al Valor Nominal de la arista en cuestión, se calcula la tolerancia o desviación sobre el valor nominal (valor absoluto de la diferencia entre el valor medio y el nominal de la arista) y la dispersión (valor absoluto máximo de la diferencia entre el valor medio de una dimensión de la probeta y cada valor aislado de la misma). Posteriormente, dependiendo del tipo de ladrillo que se tenga, se deben realizar mediciones sobre cada una de las caras del ladrillo: Tabla (cara mayor), Canto (cara intermedia) y Testa (cara menor).  Ladrillo tipo V (Visto 6 ): se debe medir las flechas en las diagonales de una tabla, un canto y dos testas.  Ladrillo tipo NV (No Visto 7 ): se debe medir una flecha en las diagonales de la tabla, canto y testa. A partir de estas mediciones, se debe clasificar la longitud de cada cara en 3 categorías:  L ≤ 25  30 ≥ L > 25  L > 30 Por lo tanto, se ha decidido crear una tabla donde se introducirán las mediciones para cada probeta y obtener los resultados en campos externos. Mediante un listado despegable se indicará la forma del ladrillo y se incluirán una serie de botones que permitirán añadir o eliminar filas en la tabla. 6 Ladrillo Visto es aquel que no se recubre con ningún acabado para su uso. 7 Ladrillo No Visto es aquel que va a quedar oculto a la hora de usarlo. Ilustración 21 - Aristas de un Ladrillo 39 En la parte superior, deberán existir botones para realizar los cálculos, guardar los datos del ensayo en la base de datos, cambiar a otro ensayo, crear y adjuntar informe a la muestra y poder consultar los informes pertenecientes al expediente. 2. 14002 – Determinación de la absorción de agua – UNE-EN 771-2003. Antes de iniciar el ensayo, se debe sumergir cada probeta (ladrillo) en agua durante 24h; de esta forma obtendremos el valor de Ladrillo Húmedo. Posteriormente, se debe calcular el peso seco de cada probeta; para ello, se secan los ladrillos húmedos en una estufa a 105±5ºC hasta masa constante (se considera que la masa es constante si la diferencia entre dos pesadas a menos de veinticuatro horas no supera el 0.2%). Con ambos valores, se calcula el porcentaje de absorción de agua de cada probeta de la siguiente forma: % 𝑎𝑏𝑠 = 𝐿. 𝐻ú𝑚𝑒𝑑𝑜 − 𝐿. 𝑆𝑒𝑐𝑜 𝐿. 𝑆𝑒𝑐𝑜 ∗100 Ilustración 22 - E.R. del ensayo Dimensión y Comprobación de Forma 40 En un principio, se creyó oportuno utilizar dos tablas para realizar las mediciones y cálculos: una para anotar el valor de las pesadas durante el secado del ladrillo y calcular su porcentaje de variación, mientras que en la otra se introduciría el peso húmedo y el peso seco (este último obtenido de la primera tabla) y se calcularía el porcentaje de absorción. Pero tras una reunión con los técnicos de laboratorio, se decidió simplificar esta pantalla con una única tabla, de forma que el proceso se simplificase y se realizase de forma más rápida. Por último, para el cálculo del valor medio de las absorciones, bastará con un campo de salida. Ilustración 23 - E.R. Absorción de agua 41 3. 14003 – Ensayo de eflorescencia – UNE 67029:95 EX. 4. 14004 – Expansión por humedad – UNE 67036. Ilustración 24 - E.R. Eflorescencia Ilustración 25E.R. Exp. por Humedad 48 16. 14161 – Planeidad de las caras – UNE-EN 772-20. 3.3.3 Generación de Informes El diseño de la generación de informes será prácticamente igual que el de la plantilla proporcionada por los técnicos de laboratorio, eliminando aquellos ensayos que no se realizan y representando los datos de dos formas: mediante tablas y campos. Las tablas se crearán con las columnas que hagan falta por cada ensayo y dos filas: una para la cabecera, con un formato distinto, y otra a partir de la cual se insertarán los datos de los ensayos. Si aplicamos formato a las celdas de la segunda fila, se repetirá durante todas las filas que se añadan para los registros que se inserten en la tabla. Ilustración 37 - Planeidad de las caras 49 3.4 Modelo de Datos Por último, para finalizar esta fase del proyecto, y a partir de la información obtenida mediante las tareas anteriores, se diseñará el modelo de datos que dará soporte al nuevo módulo del Sistema. El modelo de datos proporciona una visión global de las entidades que forman el sistema y las relaciones que existen entre ellas. En este apartado se presentarán dos modelos diferentes que ayudarán en la tarea de decidir cómo se almacenarán los datos y cómo se realizará el acceso a los mismos, facilitando la tarea del desarrollo posterior.  Modelo del Dominio, un modelo conceptual simple y de alta abstracción que indica cómo funciona el Sistema físicamente.  Modelo de Datos, un modelo más complejo y grande en el que se indicarán las entidades que participarán en la base de datos; es decir, las tablas que se usarán y las relaciones entre ellas. El modelo del dominio que se ha obtenido del sistema es el siguiente: Ilustración 38 - Diseño del Informe de Ladrillos 50 Como se puede apreciar, este modelo es lo suficientemente básico para darnos una idea de cómo funciona el Sistema: A cada muestra se le asigna una serie de Servicios y una o dos plantillas (según se requiera que tenga informe, borrador, ambas o ninguna). Cada servicio está compuesto por varios ensayos, y pueden ser asignados a multitud de muestras. Cada ensayo puede estar darse en multitud de servicios y cada plantilla puede aparecer en multitud de muestras. Para simplificar la compresión del modelo de datos que se ha diseñado, se ha dividido según el módulo al que pertenecen. 1. Entrada de Muestras El diseño del modelo de datos será simple, ya que la mayor parte del modelo existe en el Sistema. La tabla ztlb_muestras es la encargada de almacenar toda la información sobre las muestras creadas, por lo que bastará con añadir un campo para la designación del material. Como pueden existir varios tipos de designaciones y, de cara al futuro, ampliar este dato a otro tipos de materiales, se decidió crear la tabla ztlb_desmat donde, a partir del código del material y código que identifique a la designación, obtener la descripción de esta. Ilustración 39 - Modelo del Dominio 51 Observar que el conjunto de campos que forman las claves primarias de una tabla usan un campo denominado ‘MANDT’; este campo MANDT es una característica de SAP que hace referencia al cliente que se encuentra usando el sistema en ese momento, provocando que los registros que se almacenen o se quieran observar dependan de la persona que está accediendo. En cuanto a los campos de que identifican el método de muestreo y el fabricante, servirán en este diseño, modificando una serie de cosas durante la fase de desarrollo. 2. Entrada de Resultados Ya que existen muchas entradas de resultados, y a cada una se le ha designado una o más tablas, se va a mostrar por separado el modelo de datos de cada una de ellas. Se mostrará el modelo de cada uno de los servicios en el orden en el que se han realizado. Existe una consideración a tener en cuenta: todas las tablas donde se almacenen datos relativos a los ensayos deben hacer referencia a una tabla existente en el Sistema, denominada ztlb_murelser. Se trata de una tabla Ilustración 40 - Modelo de Datos: Entrada de Muestras 52 maestra (principal) que relaciona las muestras con los servicios, de ahí los tres campos que forman su clave primaria (junto al ya conocido MANDT):  IDMUESTRA: identificado único de una muestra.  AUFPL: Número de hoja de ruta de operaciones  APLZL: Contador general de la orden IDMUESTRA identifica a la muestra sobre la que se realiza el ensayo, mientras que la combinación de AUFPL y APLZL identifica al servicio. 2.1. Aspecto y Estructura. Defectos. En este tipo de ensayos bastará con una tabla en la que guardar cada uno de los datos que califican al ensayo. Además se incluyen los campos pertenecientes a la estructura zsca_auditoria, que serán los encargados de guardar la auditoria de la creación y/o modificación de cada registro. Ilustración 41 - Modelo de datos: E.R-Defectos Ilustración 42 - Campos auditoría 53 2.2. Heladicidad 2.3. Inclusiones Calcáreas 2.4. Dimensión y forma En este tipo de servicios, se crearán dos tablas: una para los resultados, similar a la de los ensayos anteriores; y otra para las mediciones, a la que se le añade un campo más como combinación de clave primaria: el campo probeta (ya que en un mismo ensayo, las mediciones se realizarán sobre varias probetas). Al igual que en los servicios anteriores, ambas tablas deben tener los campos de auditoría. Ilustración 44 - Modelo de Datos: ER-Inclusiones calcáreas Ilustración 43 - Modelo de Datos: ER-Helacididad 54 Además, como se debe diferenciar el ladrillo según la forma que tiene, el campo forma será una clave foránea a otra tabla (ztlb_ldtipoforma), donde se almacenarán los diferentes valores de forma que puedan existir (en este caso, Ladrillo Visto o Ladrillo No Visto). Ilustración 45 - Modelo de Datos: ER-Dimensión y forma 55 2.5. Longitud, Anchura y altura 2.6. Planeidad Ilustración 46 - Modelo de Datos: ER-Long., Altura y Anchura Ilustración 47 - Modelo de Datos: ER-Planeidad 56 En este modelo se ha realizado un pequeño cambio. El campo cara puede tener 2 valores, A o B, según la cara que se esté midiendo. En los ensayos anteriores, se ha resuelto mediante un identificador que referencie a otra tabla, donde se almacenan las diferentes caras; en este caso se ha optado por escoger la solución que ofrece SAP en los dominios de tipo: Al crear el dominio de datos, se especifica cuáles son los valores posibles que puede tomar este campo: 2.7. Expansión por humedad Ilustración 48 - Modelo de Datos: Ámbito de valores de un Dominio Ilustración 49 - Modelo de Datos: ER-Exp por Humedad 57 2.8. Masa Anexo D 2.9. Eflorescencia Este modelo de datos es similar a los anteriores: una tabla para mediciones por probeta y otra para resultados finales. Además se incluyen tablas para listar los distintos valores de intensidad, superficie afectada y calificación (esta última se obtiene a partir de los identificadores de intensidad y superficie). El campo calificación de la tabla ztlb_ldefloresc será el valor que más se repita de las calificaciones obtenidas. Ilustración 50 - Modelo de Datos: ER-Masa Ilustración 51 - Modelo de Datos: ER-Eflorescencia 64  PBO: existirá un módulo PBO por cada DynPro realizado. En él se llamarán a las subrutinas que cargarán los datos a mostrar o definirán el comportamiento de la ventana antes de mostrarse o al recargarse.  PAI: al igual que ocurre con los PBO, existirá un módulo PAI por cada DynPro diseñado. En él se definirá el comportamiento del Sistema tras realizar una acción; algunos ejemplos serían la introducción de datos en la pantalla, pulsar el botón de guardar, etc.  F01: módulo donde se diseñarán las subrutinas o se llamarán a los Módulos de Funciones. Por lo tanto, el programa principal deberá contener una sentencia ‘include’ por cada módulo que se realice. Ilustración 60 - Programa Principal - Sentencias Include 65 La creación de las distintas interfaces se realizará a través de la herramienta ‘Screen Painter’. Esta herramienta permite la creación de las interfaces y sus componentes de una fácil e intuitiva, ya sean campos de texto, botones, tablas o cualquier otro elemento de los disponibles. La generación de informes se realizará de una forma distinta, ya que SAP provee de una herramienta con la cual cargar un documento que funcionará como plantilla y, de forma gráfica y programación de funciones, realizar las tareas que se requieran para mostrar los datos. 4.1 Diccionario de Datos El diccionario de datos de ABAP tendrá una labor importante durante la tarea de desarrollar el software, ya que la utilización de Estructuras, Vistas, Ayudas de Búsqueda y demás elementos que proporciona el diccionario facilitarán la tarea de manejar los datos extraídos de Base de Datos y mostrarlos en el DynPro. En este caso se utilizaron los siguientes elementos:  Dominios y Elementos de Datos: utilizados para la creación de los campos de las tablas.  Estructuras: tanto Estructuras de una tabla (funcionan como un registro donde se almacenan los campos de una o más tablas, junto con otros campos que se quieran añadir) y Tipos Tablas, que funcionan como una tabla en la que cada registro es una estructura.  Vistas: funcionan como el operador JOIN de una consulta a Base de Datos, obteniendo los datos de varias tablas cuando cumplen una condición. Ilustración 61 - Screen Painter 66  Ayudas de Búsqueda: útiles para cuando se quieran mostrar por pantallas las distintas opciones que el usuario pueda seleccionar para rellenar un campo con un valor; realiza una consulta a una tabla o vista con una serie de requisitos, devolviendo los campos que hayamos definido para los registros que cumplan dicha condición; el usuario no tendrá más que pulsar sobre el registro que le interese para que este se cargue en la ventana. 4.2 Entrada de Muestras Tal y como se ha especificado anteriormente, se requiere que se modifique la Entrada de Muestras General, ya existente en el Sistema, para que dé soporte al nuevo material (Ladrillo). Por lo tanto, bastará con realizar unas pequeñas modificaciones al programa ZLB_EMGRAL, adaptándolo a los nuevos campos o valores de Ladrillo. Se deberá añadir este nuevo campo a la tabla de muestras, se creará un campo en el dynpro que funcione como referencia a él mismo en la tabla. También se creará una ayuda de búsqueda en el diccionario de datos para facilitar la tarea de selección a los técnicos. A la hora de crear la Ayuda de Búsqueda, se indica la tabla a la que se le realiza la consulta y se indican los campos que se importan (muestran al usuario) y exportan (valores que se muestran en la ventana tras su selección). Ilustración 62 - A. Búsqueda Designación Material 67 Una vez realizado este proceso, se creará la Lógica que dará soporte a esta modificación. Tal y como se ha indicado anteriormente, se separa la funcionalidad de mostrar por pantalla (PBO) de las acciones a realizar tras una interacción con la Ilustración 64 - Ejemplo Ayuda de Búsqueda Ilustración 63 - Ay. Búsqueda Designación Material 68 ventana (PAI). Para el manejo de los datos introducidos por pantalla, se utilizará una variable tabla, del mismo tipo que la tabla de muestras, donde se almacenarán temporalmente los valores introducidos desde la pantalla. El PBO se encuentra dividido en diferentes módulos, donde se indican las acciones a realizar. Existen módulos para indicar los valores predefinidos de la pantalla, otros para indicar el estado 8 (se ha dejado el que tiene SAP por defecto), inicializar los datos, etc. A continuación, nos vamos a centrar en este último módulo, que será donde vaya parte de la nueva modificación. En este caso, tendremos que mostrar por pantalla la designación del material en caso de que se haya seleccionado y el fabricante, por lo que se creará una subrutina dentro del PBO para cada una de las acciones, donde se realiza la consulta a la base de datos o se actualiza el campo de la pantalla con el nuevo valor introducido, almacenado en la variable tabla descrita anteriormente. Posteriormente, se indica la forma por la cual, a partir del código de designación, se muestra la descripción de la misma, utilizando el código de material y el código de identificación de la designación: 8 Los iconos de estado son elementos de la pantalla que se pueden usar para representar el estado del programa gráficamente. Ilustración 65 - DynPro-PBO 69 Todos los procesos de carga de datos en el PBO se realizan de la misma forma: consulta a la tabla de la base de datos que corresponda a través de los parámetros necesarios para la obtención de un registro o campo. Ahora supongamos que queremos introducir algún valor en uno de los campos de la pantalla; la ejecución de esta tarea será realizada a través del PAI, y se utilizará el bloque de procesos CHAIN….ENDCHAIN. Este bloque comprueba si se ha producido alguna modificación en uno o más campos y, en caso afirmativo, llama al módulo donde se indica la acción a realizar. En una misma pantalla se pueden tener tantos bloques CHAIN como se requieran. En el ejemplo que se muestra debajo, el módulo invocado llamará a la subrutina que carga la descripción de la designación, mostrada anteriormente. Ilustración 66 - Cargar designación 70 4.3 Entrada de Resultados Esta fase es la más extensa del proyecto y la que llevó más tiempo implementar y comprobar, ya que se deben realizar dieciséis DynPros, uno para cada ensayo, con sus correspondientes modules, subrutinas y módulos de funciones. Para realizar esta tarea, se ha utilizado el programa ZLB_ERGRAL, compuesto por una única DynPro con un campo para escribir el resultado de un ensayo; esta entrada se utiliza para todos aquellos ensayos de materiales que aún no han sido implementados. Ilustración 67 - Chain..Endchain Ilustración 68 - Ejemplo DynPro E.R. 71 Estas entradas se han desarrollado de dos formas: los ensayos más sencillos (aquellos que solo deben mostrar unos pocos datos, como se muestra en la siguiente figura) se han realizado de forma similar a la Entrada de Muestras: 1. PBO: además de asignar los valores básicos de la ventana (como por ejemplo, el estado o nombre de la misma), debe llamar a un módulo que inicialice los campos de la ventana; este módulo llamará a la subrutina pertinente donde, tras comprobar que la tabla interna del ensayo 9 está vacía (al entrar en el ensayo, esta tabla debe estar vacía ya que cuando se ejecuta el módulo aún no se ha mostrado la pantalla y, por lo tanto, no se ha podido escribir en ella), llamará a la función que realice esta carga de datos, guardándolos en la tabla interna, y asignar estos valores a los campos de la pantalla. 9 Se ha creado una tabla interna en el TOP del programa para almacenar temporalmente los datos que se inserten o modifiquen por pantalla. De esta forma se opera solamente sobre esta tabla interna y, en caso de querer guardar los datos, se llama a una función que realice este proceso sobre la tabla de base de datos. Ilustración 69 - Ejemplo código DynPro 72 Ilustración 71 - Inicializar datos ensayo Ilustración 70 - PBO Entrada Resultados 73 Como se aprecia en las imágenes superiores, se ha utilizado un diseño en capas por el cuál separar claramente la interfaz (capa de presentación) de los programas (capa de negocio) y datos (capa de negocio); Los datos se extraerán mediante llamadas a módulos de funciones, pasando como parámetros de entrada las claves que identifican la muestra y el ensayo, y como parámetro de salida se obtendrá la tabla interna donde se almacenan temporalmente los datos. Los valores de esta tabla de salida serán asignados a los campos correspondientes del DynPro, para que muestren el contenido por pantalla. Además, se ha incluido una estructura de control de errores, propia de SAP, por la cual se almacenará un valor determinado dependiendo de si la consulta a base de datos ha tenido éxito o no; dependiendo de este valor, se le asignará un tipo de mensaje, identificador, biblioteca donde buscarlos y, opcionalmente, parámetros que se usarán para formar el mensaje, que será lanzado para que el usuario pueda comprobar si la ejecución se ha realizado correctamente. En este caso, para controlar la ejecución de estos mensajes, se ha optado por comprobar que la variable propia del sistema ‘sy-subrc’ si la ejecución de una instrucción (asignación, consulta, etc.) ha sido correcta o, si por el contrario, ha habido algún fallo en ella. Por ejemplo, si tras realizar una consulta a la base de datos para hallar un registro, SY-SUBRC contiene el valor cero, la búsqueda Ilustración 72 - Mensajes ABAP 80 Posteriormente se volverá a esta parte y se explicará el funcionamiento de las fórmulas, necesarias para mostrar los datos. Pero antes, es necesario comentar cómo funciona el desarrollo del código fuente que extraerá los valores a mostrar de la base de datos y su apropiado cambio de formato, tanto para mostrar estos datos con la precisión que pide cada norma como adaptarlos a una posible plantilla en Excel. Para ello, y al igual que en las plantillas ya implementadas en el sistema, se creará un módulo de funciones al que se le pasan como parámetros de entrada los valores que identificarán el informe y algunos campos a insertar (como la firma) y devolverá tres estructuras de datos: una para los campos, otra para las tablas y otra para parámetros necesarios a la hora de generar el informe. De las dos estructuras de salida que se han mencionado anteriormente, se usarán dos en la creación del nuevo código:  ‘zslb_datos_plantillas’: Esta estructura se aprovecha de la definición de una estructura ABAP por la cual puede contener campos de una tabla u otras estructuras que referencien a tablas. Estará formada por varias estructuras, cada una de las cuales fue creada para separar los valores a devolver según al material al que pertenezcan o la función que tendrán en la creación del informe. Mencionar que al ser un tipo del diccionario ABAP, no guarda ningún dato en la base de datos, sino que los guarda en memoria durante su ejecución y posteriormente se eliminan. Ilustración 80 - FM plantilla ladrillo 81 Cada uno de los campos de la estructura no tendrá el formato de sus homólogos en base de datos, sino que contará con el formato final con el que se mostrarán en el informe; esto es debido a que durante una asignación entre tipos distintos compatibles (por ejemplo, un numero con tres decimales y otro con uno), ABAP realiza la conversión redondeando el valor o añadiendo los ceros necesarios. Ilustración 81 - Datos para plantilla 82  La otra estructura, ‘ztlb_tablasplant’ fue creada por un miembro del equipo de desarrollo hace un tiempo. Esta estructura, de tipo tabla (por lo que puede tener varios registros almacenados temporalmente) está formada por unos campos que identifican a la muestra junto a otro, de tipo cadena, en el que se almacena el nombre de la tabla que queremos almacenar; es decir, este tipo tendrá en su interior registros de varias tablas, siendo posible acceder a ellas a través de su nombre. El resto de campos, de tipo cadena, permite homogenizar todas las salidas, ya que tendrán el mismo tipo de datos. La conversión entre tipos se realiza de forma automática también, pero se debe realizar una tarea adicional: Los valores numéricos en SAP tienen un formato incompatible con los valores numéricos de Excel 10 (ya que la coma funciona como separador de millares y el punto como separador de números enteros y decimales), por lo que se debe llamar a una función que realice este cambio. A continuación se muestra una imagen desde el debugger de ABAP con esta estructura rellena: Ilustración 82 - Estructura para tablas 10 En el formato SAP se utiliza el carácter coma (,) para separar los millares y el carácter punto (.) para separar los números enteros de los decimales. En Excel, este formato es justamente el contrario: coma para separar decimales y punto para separar millares. 83 Adicionalmente, desde el Diccionario de Datos de ABAP y para aquellos ensayos en los que se necesite mostrar los datos con una precisión distinta a la utilizada en los cálculos, se creará una estructura en la que cada campo tendrá su tipo de datos final. Así, con una única sentencia ‘move-corresponding’, todos los datos se copiarán en esta nueva estructura con la precisión adecuada, no teniendo que realizar cambios sobre cada uno de ellos. Una vez introducidos los tipos a usar, se va a proceder a comentar el funcionamiento de esta función. En el interior de este módulo, se crearán distintas llamadas a módulos de funciones, de cara a separar las diferentes obtenciones de datos según su procedencia, de forma modular: existirá un módulo que cargue la designación, otro que cargue la lista de ensayos que se realicen, otros que carguen los datos de cada uno de los ensayos, etc. Para obtener los datos resultados o datos que se insertarán como campos en el informe, el procedimiento a seguir es el siguiente: se obtiene el registro a través de una consulta a base de datos, almacenándolo en una estructura del mismo tipo creada durante la ejecución de la función (también es posible crear una estructura que difiera en el número de campos, obteniendo solamente aquellos que son necesarios). Tras ajustar la precisión de estos datos tal y como se ha indicado anteriormente (en caso necesario), se llama a la función que ajusta este formato al mismo que Excel y se guarda el nuevo valor en su campo correspondiente de la estructura final (‘zslb_datos_plantillas’). Ilustración 83 - Cargar campos del informe 84 En cuanto a los módulos de funciones que tablas completas, el funcionamiento es similar pero con ciertas diferencias. En primer lugar, tras obtener los registros a través de una consulta a la base de datos, se almacenan en una variable de tipo tabla, ya sea igual a la tabla a la que hacemos la consulta o, como se ha dicho antes, creándola en la función con los campos necesarios. Se deberá recorrer la tabla creada para modificar los valores (en caso necesario) y almacenarlos en la estructura que devolverá estos valores; para ello se utiliza un bucle ‘for’, que recorrerá la tabla devolviendo su posición actual, y se almacenará el registro completo en una varible de tipo ‘field-symbol’ 11 . A partir de ella, se podrá acceder a cada campo del registro y hacer las tareas pertinentes. Por último, al estar trabajando sobre cadenas (recordar que la estructura muestra los datos en forma de cadena de caracteres), se realiza la operación ‘condense’ sobre cada una (elimina los espacios en blanco que pueda haber a la izquierda del valor) y ‘append’, que añade el registro completo a la estructura de tipo tabla. Se debe observar también como al inicio del bucle, se actualizan los valores a través de los que accederemos a estos registros para insertarlos en las tablas del informe, como el identificador de muestra, el nombre de la tabla que añadimos y la posición del registro. Por último, en este módulo de funciones, existirá un Módulo adicional que se encargará de comunicar los datos de estas estructuras con el programa que realiza la 11 Una variable de tipo field-symbol es un puntero cuyo contenido es la dirección de un objeto. Al asignar un field-symbol a un registro de una tabla, la variable apuntará al registro en cuestión, permitiendo el acceso o modificación de los valores almacenados. Ilustración 84 - Carga de tablas para informe 85 creación de informes, por lo que tan sólo tendremos que crear las fórmulas que seleccionen los datos apropiados para su realización. En la transacción ‘zgc_plantillas’, se ha indicado que la pantalla aparece dividida en dos partes: una donde se introducen las fórmulas de selección y otra donde se realizan las modificaciones visuales y se insertan campos y tablas. Volviendo a la primera zona, esta se encuentra dividida en cuatro tablas: una donde declarar variables de tipo campo, otra para declarar variables de tipo tabla, otra para declarar variables de tipo gráficas y la última para declarar imágenes. Tal y como se aprecia en la tabla superior, se inserta una fórmula para cada elemento que se quiera mostrar en el informe. Para ello se debe pulsar sobre el botón ‘Nueva Fórmula’, que se encuentra en el menú superior, y crear la fórmula haciendo referencia al origen (campo de la estructura), y nombre de destino (que será el que se utilice para la creación del campo en el documento Word). Las tablas funcionan de forma similar, pero se deberán añadir dos valores más: uno indica la posición de la tabla en el documento (es decir, si es la primera tabla que aparece, la segunda, la décima, etc.) y la otra será la variable de tipo tabla donde se almacenarán. Esta variable se crea a través del botón ‘Editar cat. campos', indicando Ilustración 85 - Plantilla y fórmulas 86 el número de campos con los que contará cada registro (de ahí el número que se añade tras el nombre; por ejemplo, ‘TT_TABLASPLANT7’ contará siete campos en cada registro). La razón de que se deban crear varias tablas similares pero con distintas columnas es que cada ensayo cuenta con datos diferentes, por lo que si se crease una común, sobrarían o faltarían columnas. En cuanto a las imágenes, se les indica el nombre del campo donde se encuentran almacenado su valor y la posición en el documento (si es parte de la cabecera o del cuerpo, hoja en la que se debe insertar y coordenadas de la posición). Una vez definida la fórmula, se debe crear la consulta que servirá para devolver los valores almacenados en memoria interna al informe. El campo ‘TIPOSELECT’ indica si se va a devolver un valor único (tipo 3), una tabla (tipo 2) o una imagen (tipo 1). Se introduce el nombre del campo, que será el que se añadirá al documento, y la consulta que devolverá este valor y lo almacenará en la variable anteriormente indicada. Ilustración 86 - Obtención de un campo Ilustración 87 - Obtención de una tabla 87 5. Pruebas e Implantación Tras desarrollar los nuevos módulos, comienza una fase de vital importancia en todo proceso de desarrollo software: el testeado y validación de los módulos, de forma que se puedan encontrar errores producidos en las fases anteriores o corroborar su correcto funcionamiento. Esta fase es de vital importancia porque, hasta ahora, estos módulos solamente han sido usados por el equipo de desarrollo y con datos de prueba. Al ser parte de un sistema ERP de una Empresa, debemos asegurar que no se produzcan errores cuando el usuario final sea el que maneje el Sistema, ya que podría suponer pérdidas, tanto de tiempo como, en el peor de los casos, de los datos almacenados en el Sistema. SAP, como cualquier entorno de software de gestión empresarial, presenta la necesidad de tener sistemas complejos (hardware y software) separados dedicados a funciones específicas. Algunos ejemplos de estas funciones pueden ser el desarrollo de software, las pruebas del mismo, formación a los usuarios finales y, la más importante de todas, la puesta en producción del software. El Sistema SAP R/3 utilizado ha contado con tres de estos escenarios, permitiendo realizar tareas específicas en cada uno de ellos: desarrollo, integración y producción.  Sistema de desarrollo: es el sistema inicial donde se origina el software. Todos los desarrollos y parametrizaciones se llevan a cabo aquí y, una vez realizadas las pruebas unitarias de los programas, se transportan al Sistema de Integración. El Sistema de Desarrollo suele contar con pocos datos, ya que se van creando como pruebas y, en ocasiones, son inconsistentes.  Sistema de Integración: en este sistema se realizan pruebas definitivas del software: pruebas integradas, pruebas de rendimiento, pruebas de usuario y pruebas de transporte.  Sistema de producción: este sistema tiene una única función: la explotación real del software. Es donde se almacenan los datos reales de la empresa y donde se ejecutan los procesos del negocio. Antes de transportar los programas o parametrizaciones a este sistema, se debe garantizar que estos no afecten ni al trabajo productivo ni a los datos reales. Por lo tanto, las pruebas básicas se realizan en Desarrollo. Una vez superadas estas pruebas, se transportan los programas, tablas y demás componentes del proyecto a Integración. Si en este sistema se detectan fallos, toda modificación de datos o código debe realizarse en Desarrollo, volviendo a transportar a Integración después de que se hallan vuelto a superar las pruebas básicas realizadas en este entorno. Una vez que se han superado todas las pruebas en el sistema de Integración, se transporta a Producción para que esté operativo de cara a la empresa. 88 La principal ventaja de la existencia de este esquema de sistemas es que evita interferir en el trabajo que realizan los usuarios día a día, a la vez que los desarrolladores pueden seguir modificando el sistema introduciendo nuevas mejoras. Para realizar este transporte entre sistemas, se usa lo que se denomina ‘órdenes de transporte’. En SAP, existen dos formas de guardar los cambios de desarrollo (elementos del Diccionario de Datos, código fuente, diseños, etc.):  Local: todas las creaciones o modificaciones se guardarán en el entorno en el que nos encontremos, no afectando a otros entornos (no podrán ser transportadas a los otros sistemas).  Órdenes de Transporte: se usan para guardar los contenidos y transportarlos entre diferentes entornos, con el fin de que el desarrollo realizado no afecte al funcionamiento del sistema. En estas órdenes de trabajo se incluirán programas, funciones, tablas, estructuras del Diccionario, documentos,… en definitiva, todo aquello que interfiera en el funcionamiento del nuevo software. Existen varias tablas de parametrización o datos que se han debido crear para dar soporte al funcionamiento de los programas; por ejemplo, en la tabla ‘ZTLB_LDINTENSIDA’ se han introducido los diferentes tipos de intensidad que pueden darse en un ladrillo al realizarse el ensayo de Eflorescencia. Estos datos deben incluirse en la orden de transporte ya que, de lo contrario, al ejecutar este ensayo en alguno de los otros sistemas, la tabla transportada no tendrá ningún registro y no funcionará correctamente. Ilustración 88 - Creación de una orden de trabajo 89 5.1 Pruebas Para comprobar el correcto funcionamiento de los programas, se han realizado diversos tipos de prueba, que se pueden categorizar de la siguiente forma:  Pruebas de caja negra 12 : a partir de los borradores de ensayos facilitados desde laboratorio (con datos reales) y la plantilla Excel que utilizan para realizar los cálculos, se ha comprobado que, en cada ensayo y para los mismos valores de los borradores, los resultados de la plantilla Excel y el programa son las mismas. Además, a través de transacciones como la SE16N (transacción que permite consultar los registros existentes en una determinada tabla), se comprueba que los datos son guardados o cargados correctamente en el programa. También se han introducido valores incorrectos para comprobar que el programa avisa al usuario de estas incorrecciones a través de los mensajes creados.  Pruebas de caja blanca 13 : Este tipo de pruebas se han realizado a través de la herramienta Debugger ABAP, permitiendo observar paso a paso la ejecución del programa, comprobar el contenido de las tablas o registros, cambiar el contenido de las variables para forzar ejecuciones distintas, etc. 12 Las pruebas de caja negra se realizan sobre la interfaz del software y consiste en proporcionar una serie de entradas para comprobar que las salidas concuerdan con las esperadas. 13 Las pruebas de caja blanca, por el contrario, se centran más en el software en sí. Se escogen distintos valores de entrada para examinar cada uno de los posibles flujos de ejecución del programa y asegurar que se devuelven los valores de salida adecuados. Ilustración 89 - Debugger ABAP 96 Tan solo quedará rellenar la tabla texto con los diferentes registros según su identificador e idioma, tal y como se muestra en la siguiente ilustración: Y el resultado de un programa que haga uso de este tipo de tablas será el que se muestra a continuación: Ilustración 100 - Transacción desde sesiones e idiomas distintos A la hora de programar, se tendrán que cambiar ligeramente las consultas ya que, si queremos obtener el texto de un registro, se deberá realizar la consulta sobre la tabla de texto, en vez de sobre la tabla padre, añadiendo una nueva restricción: el idioma Ilustración 99 - Registros de la Tabla de Texto - Designación Materiales 97 del registro debe ser igual al idioma del Sistema durante la sesión; con esta restricción, además de las que tuviéramos anteriormente, obtendremos el registro correcto. Se ha mostrado una pequeña modificación, pero la idea se puede extrapolar a todo el Sistema de la misma forma, guardando todo los textos en tablas y creando sus Tablas de Texto; de esta forma, durante la creación de pantallas bastaría con realizar consultas a bases de datos para extraer los textos en los idiomas correspondientes y mostrarlos en la pantalla en su posición correspondiente. 98 99 7. Conclusiones En este capítulo, el último de la memoria del Trabajo Fin de Grado, se hará un análisis del trabajo realizado, haciendo hincapié en aquellas partes que no resultaron tan satisfactorias o en las que, por un motivo u otro, han causado inconvenientes en la elaboración del trabajo. Además, se dará una valoración personal sobre lo aprendido y lo que significará este trabajo de cara al futuro. En este sentido, hay que decir que durante la elaboración de este Trabajo Fin de Grado se han producido una serie de retrasos que han puesto en peligro la finalización del mismo dentro de los plazos marcados. Gran parte de este inconveniente tiene que ver con la inexperiencia, ya que la fase de estudio del Sistema con el que se debía trabajar llevó un tiempo que, en caso de haber trabajado antes con él, no se hubiese llevado. Durante la toma de requisitos y diseño del modelo de datos se produjeron también una serie de inconvenientes que, de cara al futuro, sirvieron para aprender que es una fase primordial de todo desarrollo. El primer error fue utilizar únicamente las normas proporcionadas para el diseño de las pantallas de los ensayos; algunas de estas normas se encuentran desactualizadas o la normativa referente a ellas ha cambiado, por lo que algunas de las operaciones que los técnicos de laboratorio realizaban para obtener los datos de los ensayos dejaron de hacerse. Esto conllevó que una vez que el trabajo estaba en su fase final, tener que volver a diseñar varias pantallas de ensayos para poder adaptarlas al estilo de trabajo de los técnicos. Otro de los errores fue el de estudiar cada uno de los módulos o pantallas por separado, sin englobar una visión general. Esto provocó que el primer modelo de datos obtenido fuese ineficiente, con demasiadas tablas e, incluso, algunas con los mismos campos y, por lo tanto, iguales. Esto provocó tener que empezar esta fase desde el principio de nuevo, con el retraso que conllevó. El resto de inconvenientes vinieron por parte de la adaptación a la metodología de programación existente e inexperiencia, además de la inseguridad del programador que debe trabajar y hacer modificaciones en partes del sistema que son vitales para su correcto funcionamiento y que se comparten entra distintos módulos o programas, por lo que cada cambio debía ser estudiado y probado minuciosamente. Hay que destacar que en todo momento se contó con el apoyo del equipo de desarrolladores que, aunque no intervinieron en el proceso, sus consejos, advertencias e ideas fueron útiles a la hora de encontrar una solución a todos los inconvenientes encontrados. Otro inconveniente encontrado, pero de naturaleza menos técnica, fue la mala administración del tiempo a la hora de realizar esta memoria. Esto provocó que su 100 finalización se produjese muy cerca de la fecha objetivo, con la presión e inconvenientes que pueden sucederse en dichas circunstancias. Tras la finalización de este Trabajo Fin de Grado, se puede decir que el nivel de satisfacción personal y profesional es muy alto, y que el aprendizaje adquirido durante su elaboración será de gran ayuda frente a proyectos futuros y, el poder enfrentarme a los problemas anteriormente citados, conllevará que no cometa los mismo errores y que pueda prever dichas situaciones. 101 Bibliografía  ABAP IV; http://www.abap.es/  SAP NetWeaver; http://scn.sap.com/community/netweaver  ModulPool; http://www.abap.es/Descargas/Manual%20Modul-Pool%20.pdf  Tablas de texto; http://solutionssap.com/como-asociar-una-tabla-de-texto-auna-tabla-z/  Normas UNE; http://www.aenor.es/aenor/inicio/home/home.asp  Seidor (proporcionados por la empresa); Manuales de programación e introducción a SAP  Horst Keller, Sascha Krüger (2007); ABAP Objects: ABAP Programming in SAP NetWeaver; Galileo Press  Karl-Heinz Kühnhauser (2008); Discover ABAP; Galileo Press  Jesús Gómez Tenedor (2011); Desarrollo en SAP de aplicaciones para laboratorio de control de calidad en materiales; Proyecto fin de carrera, Universidad de Málaga  AENOR (proporcionadas por la empresa); Normas UNE 102 103 Tabla de Ilustraciones Ilustración 1 - Elementos de un ERP ....................................................................................................... 9 Ilustración 2 - Normas UNE .................................................................................................................. 10 Ilustración 3 - Entrada de Muestras previa .......................................................................................... 11 Ilustración 4 - Plantilla e Informe originales ......................................................................................... 12 Ilustración 5 - Flujo del Módulo de Laboratorio ................................................................................... 12 Ilustración 6 - Logo de SAP ................................................................................................................... 14 Ilustración 7 - Plataforma SAP NetWeaver ........................................................................................... 15 Ilustración 8 - SAP R/3 .......................................................................................................................... 16 Ilustración 9 - Módulos SAP R/3 ........................................................................................................... 17 Ilustración 10 - Entorno de programación ABAP .................................................................................. 20 Ilustración 11 - Diccionario ABAP ......................................................................................................... 22 Ilustración 12 - Foro de dudas .............................................................................................................. 27 Ilustración 13 - Diagrama de Casos de Uso .......................................................................................... 30 Ilustración 14 - Diagrama de Secuencia CU1 ........................................................................................ 31 Ilustración 15 - Diagrama de Secuencia CU2 ........................................................................................ 32 Ilustración 16 - Diagrama de Secuencia CU3 ........................................................................................ 33 Ilustración 17 - Diagrama de Secuencia CU4 ........................................................................................ 34 Ilustración 18 - Diagrama de Secuencia CU5 ........................................................................................ 35 Ilustración 19 - Nueva Entrada de Muestras ........................................................................................ 36 Ilustración 20 - Entrada de Resultados General ................................................................................... 37 Ilustración 21 - Aristas de un Ladrillo ................................................................................................... 38 Ilustración 22 - E.R. del ensayo Dimensión y Comprobación de Forma ................................................ 39 Ilustración 23 - E.R. Absorción de agua ................................................................................................ 40 Ilustración 24 - E.R. Eflorescencia ......................................................................................................... 41 Ilustración 25E.R. Exp. por Humedad ................................................................................................. 41 Ilustración 26 - E.R. Heladicidad ........................................................................................................... 42 Ilustración 27 - E.R. Compresión .......................................................................................................... 42 Ilustración 28 - E.R. Succión ................................................................................................................. 43 Ilustración 29 - E.R. Flexión .................................................................................................................. 44 Ilustración 30 - E.R. Inclusiones calcáreas ............................................................................................ 44 Ilustración 31 - Entrada E.R. Aspectos y Estructura ............................................................................. 45 Ilustración 32 - Entrada E.R. Masa ........................................................................................................ 45 Ilustración 33 - E.R. Dimensiones: Longitud, Altura y Anchura ............................................................. 46 Ilustración 34 - E.R. Densidad absoluta ................................................................................................ 46 Ilustración 35 - E.R. Densidad aparente ............................................................................................... 47 Ilustración 36 - Porcentaje Huecos ....................................................................................................... 47 Ilustración 37 - Planeidad de las caras.................................................................................................. 48 Ilustración 38 - Diseño del Informe de Ladrillos ................................................................................... 49 Ilustración 39 - Modelo del Dominio .................................................................................................... 50 Ilustración 40 - Modelo de Datos: Entrada de Muestras ...................................................................... 51 Ilustración 41 - Modelo de datos: E.R-Defectos ................................................................................... 52 Ilustración 42 - Campos auditoría......................................................................................................... 52 Ilustración 43 - Modelo de Datos: ER-Helacididad ............................................................................... 53 104 Ilustración 44 - Modelo de Datos: ER-Inclusiones calcáreas ................................................................. 53 Ilustración 45 - Modelo de Datos: ER-Dimensión y forma .................................................................... 54 Ilustración 46 - Modelo de Datos: ER-Long., Altura y Anchura ............................................................. 55 Ilustración 47 - Modelo de Datos: ER-Planeidad .................................................................................. 55 Ilustración 48 - Modelo de Datos: Ámbito de valores de un Dominio .................................................. 56 Ilustración 49 - Modelo de Datos: ER-Exp por Humedad..................................................................... 56 Ilustración 50 - Modelo de Datos: ER-Masa ......................................................................................... 57 Ilustración 51 - Modelo de Datos: ER-Eflorescencia ............................................................................. 57 Ilustración 52 - Modelo de Datos: ER-Flexión ....................................................................................... 58 Ilustración 53 - Modelo de Datos: ER-Huecos ...................................................................................... 58 Ilustración 54 - Modelo de Datos: ER-Absorción agua ......................................................................... 59 Ilustración 55 - Modelo de Datos: ER-Densidad absoluta..................................................................... 59 Ilustración 56 - Modelo de Datos: ER-Densidad Aparente ................................................................... 60 Ilustración 57 - Modelo de Datos: ER-Compresión ............................................................................... 60 Ilustración 58 - Modelo de Datos: ER-Succión ...................................................................................... 61 Ilustración 59 - Objetos DynPro............................................................................................................ 63 Ilustración 60 - Programa Principal - Sentencias Include ...................................................................... 64 Ilustración 61 - Screen Painter ............................................................................................................. 65 Ilustración 62 - A. Búsqueda Designación Material .............................................................................. 66 Ilustración 63 - Ay. Búsqueda Designación Material ............................................................................ 67 Ilustración 64 - Ejemplo Ayuda de Búsqueda ....................................................................................... 67 Ilustración 65 - DynPro-PBO ................................................................................................................. 68 Ilustración 66 - Cargar designación ...................................................................................................... 69 Ilustración 67 - Chain..Endchain ........................................................................................................... 70 Ilustración 68 - Ejemplo DynPro E.R. .................................................................................................... 70 Ilustración 69 - Ejemplo código DynPro................................................................................................ 71 Ilustración 70 - PBO Entrada Resultados .............................................................................................. 72 Ilustración 71 - Inicializar datos ensayo ................................................................................................ 72 Ilustración 72 - Mensajes ABAP ............................................................................................................ 73 Ilustración 73 - Módulo de Función y comprobación de errores .......................................................... 74 Ilustración 74 - Módulos PBO ............................................................................................................... 75 Ilustración 75 - Guardar datos ensayo .................................................................................................. 76 Ilustración 76 - Creación de plantilla .................................................................................................... 77 Ilustración 77 - Selección de Plantilla ................................................................................................... 77 Ilustración 78 - Crear campo plantilla................................................................................................... 78 Ilustración 79 - Insertar campo ............................................................................................................ 79 Ilustración 80 - FM plantilla ladrillo ...................................................................................................... 80 Ilustración 81 - Datos para plantilla ...................................................................................................... 81 Ilustración 82 - Estructura para tablas .................................................................................................. 82 Ilustración 83 - Cargar campos del informe.......................................................................................... 83 Ilustración 84 - Carga de tablas para informe....................................................................................... 84 Ilustración 85 - Plantilla y fórmulas ...................................................................................................... 85 Ilustración 86 - Obtención de un campo .............................................................................................. 86 Ilustración 87 - Obtención de una tabla ............................................................................................... 86 Ilustración 88 - Creación de una orden de trabajo ............................................................................... 88 105 Ilustración 89 - Debugger ABAP............................................................................................................ 89 Ilustración 90 - Ejemplo de ejecución del debugger ............................................................................. 90 Ilustración 91 - Visualizar contenido de tabla en el debugger .............................................................. 91 Ilustración 92 - Cambiar contenido de una variable en el debugger .................................................... 91 Ilustración 93 - Transport Management System .................................................................................. 92 Ilustración 94 - Tablas de Texto ............................................................................................................ 93 Ilustración 95 - Inicio de sesión con el idioma Inglés ............................................................................ 94 Ilustración 96 - Tabla de designaciones ................................................................................................ 94 Ilustración 97 - Tabla de Texto de las designaciones ............................................................................ 95 Ilustración 98 - Crear referencia Tabla de Texto .................................................................................. 95 Ilustración 99 - Registros de la Tabla de Texto - Designación Materiales ............................................. 96 Ilustración 100 - Transacción desde sesiones e idiomas distintos ........................................................ 96