Aplicación para el proceso de control de calidad de materiales con SAP

1 2 3 ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA INFORMÁTICA GRADO EN INGENIERÍA INFORMÁTICA, MENCIÓN SISTEMAS DE INFORMACIÓN Aplicación para el proceso de control de calidad de materiales con SAP An application for the process of materials quality control using SAP Realizado por Yasser Aoujil Tutorizado por Antonio Maña Gómez Departamento Lenguajes y Ciencias de la Computación UNIVERSIDAD DE MÁLAGA MÁLAGA, noviembre de 2016 Fecha defensa: El Secretario del Tribunal 4 5 Resumen: Este manuscrito recoge la memoria del Trabajo de Fin de Grado (TFG) de Yasser Aoujil, describiendo todas las tareas llevadas a cabo para crear un sistema de Control de Calidad del material de Morteros (en lo sucesivo denominado CCM) usando SAP. SAP es una empresa alemana que ofrece soluciones para le gestión de empresas en todos sus niveles, su producto principal es SAP-ERP, un sistema para le gestión integral de empresas, compatible con la mayoría de sistemas operativos, hardware o base de datos que existen. Se caracteriza por ser altamente configurable y personalizable. Para ello SAP tiene su propio lenguaje de programación ABAP que sirve para desarrollar nuevas o modificar las aplicaciones realizadas sobre dicho sistema. Se ha estructurado esta memoria presentando en primer lugar una parte introductoria en la que se describe el entorno (la empresa CEMOSA) donde se desarrolló el TFG y se presentan brevemente los fundamentos de la tecnología SAP y su lenguaje de programación ABAP. En segundo lugar se describe el análisis, diseño, implementación y prueba del CCM dentro del modulo de SAP del laboratorio. Este modulo es usado por la empresa CEMOSA para gestionar las tareas que se hacen en el laboratorio físico desde la toma de datos de una nueva muestra de un tipo de material, hasta la generación y envío de informes sobre la calidad de dicha muestra al cliente que la mandó, pasando por la realización y archivo de resultados de los cálculos de los ensayos hechos sobre la muestra conforme con las normas UNE. Palabras claves: ERP, SAP, normas UNE, ABAP, ABAP Workbench, dynpro, módulo de función, grupo de funciones, Module, transacción, report, borrador, plantilla de Informe, control de calidad de materiales, CEMOSA, técnico de laboratorio, operadores de laboratorio, ensayo. Abstract: This manuscript summarizes the work carried out by Yasser Aoujil in relation to his “Trabajo de Fin de Grado” (TFG) and describes all the tasks carried out to create the Quality Control system of the Mortars material (hereinafter referred to as CCM) using SAP. SAP is a German company that offers solutions of businesses management at all levels, its most important product SAP-ERP is a system for the comprehensive business management, adaptable with most operating, hardware or database systems that exists, it is characterized by being highly configurable and customizable, hence it 6 has its own SAP ABAP programming language used to develop new or modify existing applications. The manuscript is structured first presenting the company CEMOSA where the GFP is developed and the technology of SAP and its ABAP programming language. The main part of the manuscript is devoted to the description of the analysis, design, implementation and testing of CCM within the SAP’s laboratory module. This module is used by company CEMOSA to manage tasks that are done in the physical laboratory, starting from taking data of a new material sample, until the generation and sending of reports on the quality of the sample to the customer who ordered the quality control, passing through the realization and saving of the calculation’s results of the tests made on the sample in accordance with the UNE standards. Keywords: ERP, SAP, UNE Standards, ABAP, ABAP Workbench, dynpro, function module, function group, module, transaction, report, draft, report template, Materials Quality Control, CEMOSA, laboratory technician, laboratory operator, essay. 7 Tabla de contenido 1. Introducción .................................................................................................. 9 1.1. La empresa CEMOSA ......................................................................................9 1.1.1. Descripción general ............................................................................................. 9 1.1.2. Descripción del departamento de informática ................................................... 9 1.2. Motivación ...................................................................................................... 10 1.3. Objetivos del TFG .......................................................................................... 11 1.3.1. Objetivos generales ........................................................................................... 11 1.3.2. Objetivos específicos del TFG ............................................................................ 12 1.4. Metodología .................................................................................................... 14 1.4.1. Pautas y generalidades sobre el desarrollo ...................................................... 14 1.4.2. Planificación ...................................................................................................... 15 1.5. Estado del arte ............................................................................................... 17 1.5.1. Descripción de la solución ................................................................................. 17 1.5.2. Proceso anterior al TFG ..................................................................................... 17 1.5.3. Solución alternativa: HCLabWin ........................................................................ 18 1.5.4. Conclusión ......................................................................................................... 21 1.6. Entorno de desarrollo ................................................................................... 22 1.6.1. La empresa SAP ................................................................................................. 22 1.6.2. SAP Business Suite............................................................................................. 23 1.6.3. SAP NetWeaver ................................................................................................. 23 1.6.4. SAP ERP ............................................................................................................. 26 1.6.5. ABAP 4 ............................................................................................................... 27 1.7. Estructura de la memoria ............................................................................. 34 2. Preparación previa ..................................................................................... 36 3. Análisis y diseño ......................................................................................... 38 3.1. Definiciones, actores .................................................................................... 38 3.2. Requisitos funcionales ................................................................................. 39 3.3. Requisitos no funcionales............................................................................ 41 3.4. Casos de uso ................................................................................................. 41 3.5. Diagramas de secuencia .............................................................................. 42 3.6. Diseño ............................................................................................................. 50 3.6.1. Entrada muestras .............................................................................................. 51 3.6.2. Entrada de resultados ....................................................................................... 53 3.6.3. Borradores......................................................................................................... 65 3.6.4. Informes ............................................................................................................ 66 3.6.5. Listado de resultados ........................................................................................ 66 3.6.6. Correo de correspondencias ............................................................................. 67 4. Implementación ........................................................................................... 68 4.1. Diccionario de datos ..................................................................................... 70 4.1.1. Tablas ................................................................................................................ 70 4.1.2. Elementos de datos ........................................................................................... 78 4.1.3. Estructuras ........................................................................................................ 78 4.2. Entrada de muestras ..................................................................................... 81 4.3. Entrada de resultados ................................................................................... 84 4.3.1. Módulo PBO ...................................................................................................... 85 4.3.2. Módulo PAI ........................................................................................................ 86 4.4. Borrador ......................................................................................................... 91 4.4.1. Módulo de función ............................................................................................ 91 8 4.4.2. Diseño................................................................................................................ 93 4.4.3. Configuración de tablas .................................................................................... 95 4.5. Listado ALV .................................................................................................... 96 4.6. Informe .......................................................................................................... 100 4.6.1. Diseño Word ................................................................................................... 100 4.6.2. Grupo de funciones ......................................................................................... 103 4.6.3. Tabla de configuración .................................................................................... 105 4.7. Correo de correspondencias ..................................................................... 106 5. Pruebas ...................................................................................................... 110 5.1. Entornos de SAP ......................................................................................... 110 5.2. Pruebas ......................................................................................................... 112 5.2.1. Pruebas de caja blanca .................................................................................... 112 5.2.2. Pruebas de caja negra ..................................................................................... 113 6. Implantación y despliegue en producción ............................................ 116 7. Conclusiones ............................................................................................. 117 7.1. Objetivos cumplidos ................................................................................... 117 7.2. Dificultades encontradas ............................................................................ 117 7.3. Mejoras posibles ......................................................................................... 118 8. Bibliografía y referencias ......................................................................... 119 9. Ilustraciones, códigos y tablas ............................................................... 120 Anexo A. Pantallas de resultados .................................................................. 123 Anexo B. Ejemplo de Informe de mortero de albañilería ............................ 125 Anexo C. Ejemplo de Informe de mortero de revoco .................................. 131 Anexo D. Ejemplo de Borrador ....................................................................... 139 9 1. Introducción 1.1. La empresa CEMOSA 1.1.1. Descripción general CEMOSA acrónimo de Centro de Estudios de Materiales y Control de Obras, S.A, es una empresa Andaluza fundada en 1972, que ha crecido tanto a nivel nacional en varias ciudades, como internacional. CEMOSA es una compañía especializada en ofrecer servicios de ingeniería y control de calidad en el ámbito de la construcción y obra civil. La empresa CEMOSA consta con varias líneas de negocio que se resumen a continuación:  Consultoría y Proyectos de Ingeniería   Control de calidad  Geotecnia  Edificación  Seguridad y salud  Certificación de calidad  I+D+I CEMOSA actúa como Entidad de Certificación de Producto, y ha recibido por parte del Ministerio de Industria la calificación de Organismo Notificado para el Marcado CE de productos de construcción, siendo la única empresa andaluza en obtener este reconocimiento que la faculta para actuar en el ámbito de la Comunidad Europea. También actúa en siete otros países, Panamá, Brasil, Bolivia, Colombia, Ecuador, Chile y Costa Rica. CEMOSA consta con su propio departamento de informática -en el cual se desarrolla el TFGque le proporciona soporte al negocio, a continuación se detallan las características de este departamento. 1.1.2. Descripción del departamento de informática Se ha desarrollado el TFG en el departamento de sistemas de información. Este departamento consta de varios trabajadores que se muestran en la ilustración 1, el equipo asignado durante el TFG es el de Programadores dentro del equipo de desarrollo. Este equipo se encarga de llevar a cabo todas las tareas necesarias para dar soporte a la empresa mediante el desarrollo y mantenimiento de SAP. 16 Se han hecho nuevas reuniones con el jefe de desarrollo para acordar un diseño optimo de todos los componentes a desarrollar (tablas de base de datos, estructuras de datos, pantallas de entrada de datos y funciones…) usando todos los recursos anteriores. 4. Implementación: en esta fase se desarrolla el código y se crean todos los componentes necesarios para concretizar el diseño anterior. 5. Pruebas: En esta fase se hacen varias pruebas a todos los componentes del sistema, de manera que se simule una ejecución de todo el flujo de control de una muestra de morteros, pasando por las siguientes etapas:  Creación de muestras y su guardado en las tablas correspondientes, y asociar a la muestra en el momento de su creación los servicios 4 que se le van a realizar. Además se debe asignar a la muestra la plantilla del informe final donde se recogen los resultados y el borrador del laboratorio.  Generación de borradores de los servicios asociados con la muestra.  Introducción de mediciones en pantallas de cálculos de resultados, y guardado de resultados finales en las tablas de la base de datos.  Generación de listados que contienen todos los resultados de los ensayos, junto con datos generales de la muestra.  Generación de una tabla en formato HTML en el cuerpo del correo que se manda al cliente, con resumen de todos los ensayos y sus resultados. Este correo tiene adjuntado el informe final.  Generación del informe final.  Prueba de envío de correo de correspondencias a los interlocutores.  Aprobación de los resultados por el director técnico del laboratorio. Las pruebas incluyen de manera implícita la verificación de que los nuevos componentes funcionan de manera correcta como parte de todo el sistema, sobre todo en las funciones desarrolladas que tienen dependencias en código, tablas de base de datos o pantallas de usuario que ya existían. 6. Integración en el sistema de producción: en esta fase se realiza la integración de todos los nuevos componentes el sistema de producción real. 4 Un servicio representa un ensayo de control de calidad que el cliente de CEMOSA solicita para realizar sobre una muestra. 17 7. Documentación: en esta fase se generan documentos que siguen una plantilla de documentación técnica en la que se detallan todos los aspectos desarrollados para facilitar el mantenimiento correctivo o evolutivo. También se generan los manuales de usuario que faciliten el uso de las nuevas funcionalidades. 1.5. Estado del arte 1.5.1. Descripción de la solución Este trabajo de fin de grado forma parte de un sistema mas amplio y mas complejo en el que interactúan todas las áreas de gestión de la empresa, por lo que este desarrollo es muy especifico a la empresa CEMOSA, también es muy dependiente de las operaciones relacionadas con la línea de negocio de control de calidad de materiales que representa un 50% del negocio de la empresa. Entonces para poder analizar otras posibilidades que podría usarse como solución a la automatización del control de calidad de morteros vamos a definir los requisitos más importantes que debe tener cualquier solución viable al problema. 1. Software que permite hacer cálculos y guardar datos de ensayos realizados sobre muestras, además de poder conectarse con cualquier sistema de base de datos para almacenar la información. 2. Fácil y eficiente en términos de integración con otros módulos como finanzas, contratación, gestión de proyectos y expedientes de la empresa, gestión comercial y gestión de personal. 3. Configurable para poder adaptarse a los cambios en normativas que implican rediseño o modificaciones (Ej. Cambio de precisión en decimales). 4. Buena integración con varias tecnologías para gestionar documentos electrónicos (PDF, Office Word o Excel) tanto de entrada como de salida al sistema. 1.5.2. Proceso anterior al TFG A Continuación se listan las operaciones que se hacen el laboratorio antes de su desarrollo del TFG, al controlar la calidad de una nueva muestra de morteros:  Se crea una nueva muestra de morteros usando la pantalla de SAP genérica para la entrada de muestras de los materiales.  Se asocian plantillas de borradores hechas con Excel.  Se asocian plantillas de informes de Word  El técnico que realiza los ensayos imprime los ficheros de Excel como borradores para apuntar los resultados obtenidos.  Otro técnico de laboratorio introduce los datos del borrador al Excel que realiza los cálculos según las normas UNE.  Las tablas de resultados se copian en otro fichero Word y se formatea, y se le añaden los datos del cliente, laboratorio, ensayos realizados y cualquier dato que impone la norma sobre los informes. 18  En ultimo se manda un correo a los clientes, con el informe de Word adjuntado. En la ilustración 4 se presenta un diagrama de proceso de negocio que muestra las diferentes operaciones que se hacen anteriormente al desarrollo al TFG para el control de una muestra. Ilustración 4 proceso de negocio de control de morteros anterior al TFG 1.5.3. Solución alternativa: HCLabWin 1.5.3.1. Descripción HCLabWin es una aplicación diseñada específicamente para la gestión de laboratorios de control de calidad de materiales de construcción. Se ha desarrollado en el año 1995 por una pequeña empresa de Murcia, hasta ahora siguen dando soporte a muchos laboratorios de ensayos de calidad en todo el territorio español. HCLabWin permite principalmente las siguientes operaciones:  Creación, impresión y control de los presupuestos emitidos y aceptados.  Control de llamadas de clientes para recogidas de material.  Libros de registro de muestras y ensayos.  Confección automática de las actas a partir de los resultados de cada ensayo y su impresión a cada destinatario de la obra.  Facturación manual o automática de estos ensayos.  Contabilización de las facturas.  Facturas de compras a proveedores.  Control de cobros de facturas.  Amortizaciones contables. 19 1.5.3.2. Ventajas HCLabWin abarca la mayoría de los ensayos de control de calidad de materiales que la normativa española especifica, eso hace de HCLabWin una buena decisión para controlar el material de morteros. Esta solución cumple con el primer requisito de tener la posibilidad de realizar los cálculos y guardar los resultados de los ensayos. También es integrable con Microsoft Excel para la introducción y generación de hojas de cálculo. Por último esta aplicación permite flexibilidad y adaptabilidad para ajustarse a cualquier cambio o especificación de una normativa, o estilo de un laboratorio a nivel de formato de datos o informes. 1.5.3.3. Desventajas Aunque HCLabWin es específico de ensayos de control de calidad de materiales de construcción, y con eso serviría para el objetivo especifico del TFG que es la informatización y optimización del control de calidad de morteros mediante uso de software, aun no cumple con unos requisitos muy importantes para la empresa CEMOSA en general y el departamento de informática en especial por la filosofía que tiene, desde la implantación de SAP, para poder tener toda la empresa gestionada mediante el mismo sistema, con una base de datos centralizada. HCLabWin tiene el defecto de que es enfocado a laboratorio de control, eso hace que sea muy bueno para una empresa que solo se dedica a control de materiales, o pequeños laboratorios, pero una empresa como CEMOSA que está en varios país, con diferentes líneas de negocios que pueden cruzarse en su gestión en el sistema de información por lo que deben estar manejados por el mismo sistema y deben estar bien integrados para que el control sea muy alto y se evite cualquier tipo de error. Un ejemplo que se puede dar que muestra la importancia de integrar todos los módulos entre si en la misma la aplicación y con una base de datos centralizada es, CEMOSA puede tomar un proyecto de geotecnia, que es una de las líneas de negocio importantes de la empresa, para la construcción de una obra, y también puede hacer oferta a la empresa constructora de control de materiales durante el periodo de construcción, de esta manera un proyecto tiene varios servicios que pertenecen a diferentes líneas de negocio que se traduce en términos de SAP en diferentes módulos. Otra desventaja de HCLabWin es su limitación en respecto a la base de datos que solo se integra con el sistema Firebird, y tampoco se integra con la tecnología ADOBE que juega un rol importante en el ERP de CEMOSA para la generación de documentos de laboratorio como los borradores. Todo eso aparte del hecho de que si se opta por el uso de HCLabWin, habrá una dependencia de la empresa fabricante, con el riesgo de que si ocurre algún problema con la empresa dueña del software por ejemplo que se cierre o que ya no den soporte, la empresa CEMOSA se queda incapaz de hacer el mantenimiento y eso supone un riesgo para la línea de negocio de control de 20 calidad de materiales que depende cada vez mas del sistema de información implantado. La ilustración 5 muestra como quedaría la arquitectura del sistema si se opta por usar HCLabWin en vez de añadir las funcionalidades de control de mortero al modulo de laboratorio de SAP, con la consecuencia de tener que investigar como poder comunicar los otros módulos de SAP con HCLabWin. Mientras que en la ilustración 6 se ve como el modulo de laboratorio forma parte de los módulos de SAP y internamente abarca como un componente el sistema de control de morteros, en este caso será un modulo hecho a medida pero que corre sobre la misma plataforma y no presenta ningún problema comunicarlo con otros módulos, ya que todos ellos se basan en el lenguaje de programación ABAP. Ilustración 5 Control de mortero usando HCLabWin Ilustración 6 Control de mortero integrado en SAP-LAB con ABAP 21 1.5.4. Conclusión Después de al análisis anterior, podemos concluir que la mejor opción es desarrollar en ABAP todas las funcionalidades para añadir el flujo de control de morteros al modulo de laboratorio. La ilustración 7 muestra cómo quedaría el diagrama de proceso de negocio al implementar el nuevo transversal de morteros, a partir de ese diagrama podemos apreciar cambios en las operaciones realizadas por los técnicos que ya podrán aprovechar el sistema de información para cumplir sus tareas diarias. Entre los beneficios de las nuevas funcionalidades encontramos:  La reducción de actividades realizadas por los técnicos usuarios del sistema de información  La externalización de cualquier control de corrección de información (en borradores, informes o resultados) al sistema de información de manera que el departamento de informática se encarga de asegurar el sistema cumple con todos los requisitos, una vez aprobados por el laboratorio se despliegan en producción para su uso.  Facilidad de mantenimiento evolutivo o correctivo, por ejemplo si hay cualquier cambio en una normativa con respecto a algún ensayo, el cambio es más ágil.  El técnico que usa el sistema solo se tiene que encargar de realizar sus operaciones de forma mas eficiente, y sobre todo, mas controlada (quién, cuándo, qué).  Reducción de tiempos de realización de las tareas.  Para la empresa CEMOSA, la reducción de los tiempos de realización de trabajos supone un gran aumento de beneficio por la optimización de operación de producción. 22 Ilustración 7 proceso de negocio de control de morteros posterior al TFG 1.6. Entorno de desarrollo Este TFG se ha desarrollado alrededor de la tecnología SAP, usando varias de las tecnologías que ofrece como el lenguaje de programación ABAP, interacción con la base de datos, desarrollo de interfaces de usuario y gestión de documentos. 1.6.1. La empresa SAP SAP SE es una empresa multinacional alemana, creada en 1972, dedicada al diseño de productos informáticos de gestión empresarial, tanto para empresas como para organizaciones y organismos públicos. Las soluciones que ofrece SAP abarcan variedades de aplicaciones que responden a las necesidades en todos los áreas de gestión y organización empresarial, por lo que el producto más famoso de la empresa es SAP ERP que forma parte de un sistema más complejo y amplio denominado SAP Business Suite. La robustez y la fiabilidad de las soluciones SAP se deben a que todas la aplicaciones que ofrecen se basan sobre una plataforma denominada 23 NetWeaver que asegura una coherencia, consistencia y optimización de las aplicaciones SAP y la comunicación entre ellos. 1.6.2. SAP Business Suite SAP Business Suite es un conjunto de aplicaciones de gestión empresarial específicos para un área de negocio, desarrollado sobre la plataforma NetWeaver, que hace que todas las aplicaciones estén totalmente integradas y compatible entre si, y funciona con la cualquier tipo de base de datos, gracias a la abstracción que añade la plataforma NetWeaver. En la última versión de SAP llamada HANA (High Performance Analytic Appliance), la SAP Business Suite funciona con el nuevo sistema de base de datos de SAP llamado también Hana que se basa en una sofisticada arquitectura de carga de todos los datos en memoria principal. SAP Business Suite sigue una estructura modular de sus aplicaciones, actualmente se compone de cinco módulos: 1. SAP ERP para la planificación de recursos empresariales. Es el más conocido y más importante ya que ofrece soporte a procesos esenciales para las empresas: recursos humanos, gestión de almacén, contabilidad… 2. SAP CRM (Customer Relationship Management) para la gestión de relaciones con los clientes por ejemplo marketing, post-venta, deudores… todas esas funcionalidades son importantes para alcanzar y fidelizar potenciales clientes. 3. SAP PLM (Product Lifecycle Management) para la gestión de ciclo de vida de producto, con esta aplicación las empresas pueden optimizar y acelerar procesos conllevando reducción de costes. 4. SAP SCM (Supply Chain Management) para la gestión de las cadenas de suministro, con esta herramienta las empresas resuelven el problema de falta de suministro para alcanzar reducción de costes y satisfacción de clientes. 5. SAP SRM (Supplier Relationship Management) para la gestión de (Dolinskaja)relaciones con los proveedores. Cuando crece el negocio de esta empresa una solución de este tipo se impone, ya que cada proveedor tiene sus propios albaranes, lotes, facturas, precios… 1.6.3. SAP NetWeaver SAP NetWeaver es una plataforma abierta, desarrollada por SAP como una tecnología que integra todos los sistemas de SAP como Business Suite, SAP Portal o SAP Business Warehouse, la ilustración 8 [1] describe la relación entre todos estos sistemas. Además NetWeaver permite a los desarrolladores, mediante herramientas integradas de desarrollo, añadir funcionalidades a medida a cualquiera de las aplicaciones de SAP para que se adapten a las necesidades de la empresa. El 24 desarrollo se puede realizar con Java pero lo mas usual es que se haga en el propio lenguaje ABAP sobre el que se basa todo el sistema mediante el uso de ABAP Workbench, ilustración 9, que es el entorno de desarrollo usado durante todo el TFG para la creación de todos los componentes (interfaces de usuario, tablas de base de datos, código fuente…). NetWeaver hace que la integración de SAP con otros sistemas de otras tecnologías como Microsoft .Net, Sun Java EE o IBM Sphere, todo eso gracias a su implementación basada en estándares abiertos y la implementación de la mayoría de los protocolos más importantes como HTTPS, SSL, LDAP. El acceso simultáneo es seguro y escalable gracias al sistema de autenticación, administración de usuarios, firma digital y gestión de certificados que todos se ejecutan sobre el servidor de aplicaciones. La ilustración 10 [2] muestra la arquitectura de la plataforma SAP NetWeaver que a continuación se explican los elementos que componen su cola: 1. People Integration: asegura que los usuarios tengan la información que necesitan para hacer su trabajo. 2. Information Integration: se utiliza para gestionar todos los datos relevantes para el negocio. Esto incluye los datos de su propio negocio y datos a terceros. 3. Process Integration: permite a procesos de negocio de navegar a través de sistemas heterogéneos, que se consigue intercambiando datos en formato XML o usando servicios web. 4. Application Platform: abarca ABAP Workbench y Java Enterprise Edition en un único de entorno. Garantiza la independencia con los sistemas de base de datos y de sistemas operativos. Ilustración 8 Relaciones entre diferentes sistemas que componen una instalación completa de SAP 25 Ilustración 9 ABAP WorkBench Ilustración 10 cola de SAP NetWeaver 32  Estructura: son componentes que puedan tener cualquier tipo, son parecidos a las tipos estructurados de C++ pero ofrecen una funcionalidad mucho mas amplia dentro de ABAP por ejemplo se puede hacer un select de un registro de una tabla dentro de una estructura de datos.  Tipo tabla: describen la estructura de una tabla interna. Otros elementos muy importantes que tiene el diccionario de datos son:  Dominio: El dominio se utiliza para la definición técnica de un campo de tabla, como tipo de campo y longitud, mientras que el elemento de datos le da una definición semántica al dominio en el contexto de negocio.  Ayuda de búsqueda: es una funcionalidad avanzada de SAP que da soporte al usuario para buscar posibles valores de un campo.  Vistas: actúan como tablas pero no ocupan espacio. Actúan como tablas virtuales, es decir que no tienen existencia física. Se usan para crear un subconjunto de los datos de una tabla, o combinar varias tablas usando joins. La ilustración 16 [3] muestra un ejemplo de una tabla de cliente que hay que crear con el diccionario de datos con la siguiente información:  Nombre completo: separando apellidos y nombre.  Dirección: Separando en varios niveles las información ciudad, dirección, zip,....  Teléfono: el cliente puede tener varios teléfonos. Ilustración 16 Tabla de cliente con estructura definida por el usuario A bajo nivel en la base de datos la tabla de Numbers será una tabla con una clave foránea de Customer, pero estos detalles son transparentes al nivel del diccionario de datos y a nivel de ABAP, también podemos ver que los campos Name y Address de la tabla Customer son de tipo estructurado y en especial el campo de Address es una estructura de estructuras. El diccionario de datos no tiene un límite con respecto al anidamiento de los tipos dentro de otros, eso 33 permite una potente manera de presentar los objetos y las características de los elementos que los componen. 1.6.5.6. Tipos de datos básicos A continuación se muestran los tipos básicos del lenguaje ABAP con sus valores iniciales y descripción. Una de las características mas notables es la ausencia de un tipo de lógico, como en otros lenguajes (bool, boolean) que admiten valores de true o false, en ABAP no existen este tipo de datos ni valores, por lo que para usar una variable lógica simplemente se crea un variable de tipo CHAR y tamaño 1 y ya luego según su contenido se evalúa a true o a false. Ilustración 17 Tipos de datos básicos de ABAP [4] 1.6.5.7. Tipos de programas en ABAP Igual que en otros lenguajes de programación, existen programas que se ejecutan, y otros que dan soporte a los ejecutables más conocidos como librerías, paquetes, etc. A continuación se detallan los tipos de programas de ABAP:  Programas ejecutables, que se asocian con una transacción como se ha explicado en el apartado 1.6.5.2.  Librerías o programas no ejecutables que dan soporte al resto de programas: o INLCUDEs: se usan en programas de gran tamaño para modularizar. o Subrutinas: usados en programas para encapsular funcionamiento que puede repetirse. 34 o Grupos de funciones: una librería que contiene varias funciones accesibles desde cualquier programa. Las funciones declaradas dentro de un grupo de función tienen nombre que les identifica de forma univoca en todo el sistema. SAP viene configurado con una inmensa variedad de programas de todos los tipos y para poder diferenciarlos de cualquier otro programa hecho a medida, se impone nombrar los programas de usuarios empezando con la letra Z. Lo mismo ocurre con tablas de base de datos, vistas o cualquier otro elemento del diccionario de datos. 1.6.5.8. Otras herramientas Además de SAP, se han usado las siguientes herramientas para el desarrollo del TFG:  Citrix: sistema de virtualización usado para el acceso remoto al servidor donde está instalado SAP.  Microsoft Word, Excel para diseño de informes y pruebas de cálculos y escritura de la memoria.  Microsoft Visio para diseño de diagramas.  www.gliffy.com para desarrollo de diagramas.  Magicdraw para diseño UML.  ADOBE Livecycle: herramienta usada para diseñar los borradores, está integrada dentro de SAP. 1.7. Estructura de la memoria La estructura de la memoria refleja la planificación fijada para el TFG, de manera que cada capitulo expone una fase del desarrollo del proyecto. Como ya se ha mencionado, se ha seguido la metodología de desarrollo en cascada para que este proyecto no impacte en los módulos y funcionalidades que ya existían. Aunque se debe notar que se han hecho varios cambios durante el desarrollo, volviendo a fases anteriores para mejorar o corregir aspectos que no se hayan aclarado bien con los responsables del laboratorio en las reuniones preparatorias. Esta memoria esta organizada según la estructura siguiente: 1. Capitulo de Introducción: en esta parte se presenta el contexto de este trabajo, como la empresa CEMOSA, los objetivos y el entorno de trabajo SAP. 2. La parte de desarrollo: se compone de las siguientes capítulos: a. Preparación previa: en este capítulo se explican las tareas llevadas a cabo al inicio del proyecto, como recopilación de las normas y su estudio para poder implementar sus especificaciones luego en el sistema. También se exponen los diferentes documentos facilitados por los responsables del laboratorio para entender las necesidades que hay que resolver. 35 b. Análisis y diseño: se detallen los requisitos, funcionales y no funcionales, obtenidos a partir de los documentos y reuniones. También se detallan los diagramas de casos de uso y de secuencia, además del modelo de dominio y de datos. c. Implementación: se exponen los componentes desarrollados, y se detallan ejemplos y partes del código. En la memoria se pondrán partes importantes del código que ilustran el desarrollo, el código completo no se puede adjuntar por la complejidad que tiene SAP en el sistema de almacenamiento de código que no usa ficheros, pero en la memoria se ilustran las partes más importantes del código. d. Pruebas: se detallan las tareas de testeo llevadas a cabo para la verificación del correcto funcionamiento de todo el sistema, para eso se proporcionan varias capturas de pantalla de secuencias de ejecución del sistema. e. Implantación y despliegue en producción: se muestra el proceso de despliegue en producción del nuevo sistema y su integración con el sistema ya existente mediante parametrización de varias tablas de base de datos de configuración. 3. Capitulo de conclusiones: en esta parte final se reflexionara sobre este trabajo y como podría mejorarse. También se exponen los conocimientos adquiridos y la evolución personal y profesional. 4. Referencias bibliográficas 5. Anexos 36 2. Preparación previa El control de calidad de materiales de construcción se rige por las normas de estándar españolas que son también una implementación de las normativas europeas. Estas normas especifican las características de las herramientas con que se hacen los ensayos con todos los detalles tanto para la recogida de información de muestras y sus datos, como para procedimiento de ensayos, expresión y formulas de cálculos, por lo tanto estos documentos son muy importantes para el diseño del sistema. CEMOSA dispone de las normas que se aplican al material de morteros que son las normas UNE. Las normas UNE-EN son la versión española de las normas europeas que han sido propuestas, desarrolladas y elaborados por varios expertos de los estados miembros de la unión europea junto a entidades implicadas en sectores industriales y tecnológicos relacionadas con la actividad objeto de la norma. La versión española debe estar aprobada por los Comités Técnicos de Normalización (CTN) de la Asociación Española de Normalización y Certificación (AENOR). A pesar de su importancia, estas normas están expresadas en un lenguaje muy técnico, que para una persona con un perfil de ingenierías relacionadas con la construcción y los materiales, le resulta bastante fácil de entender y analizar. Por esto el departamento de laboratorio ha facilitado varios documentos (Excel, Word, imágenes, textos) que simplifican el análisis de las normas y la extracción de los requisitos. Dentro de los siguientes apartados se irán añadiendo capturas de pantalla de los documentos adicionales para poder explicar el origen de las decisiones de diseño. Al final de las preparaciones se creado un foro dentro del intranet de CEMOSA, ilustración 18, desde el cual se pueden hacer preguntas sobre temas relacionados con el desarrollo del sistema. Una vez añadida una nueva entrada al foro se avisa a las partes interesadas en este TFG, principalmente son el alumno, jefe de desarrollo, responsable de ensayos en el laboratorio. 37 Ilustración 18 foro de dudas dentro del intranet de CEMOSA 38 3. Análisis y diseño En este apartado se detallan las fases realizadas para diseñar el sistema. Los pasos seguidos son los típicos en el desarrollo de software, empezando con la definición de los actores, requisitos y luego usarlos para modelar diagramas de casos de uso y de secuencia que permitan tener una visión detallada sobre lo que se tiene que realizar. 3.1. Definiciones, actores Definiciones y palabras claves:  Muestra programada: es una muestra que ya se han introducido sus datos en el sistema.  Muestra no programada: es una muestra que todavía no tiene entrada en el sistema.  Borrador de laboratorio: hoja que se imprime y que tiene campos y tablas para que el operador que hace los ensayos apunte en ella las mediciones y datos obtenidos de maquinas usadas.  Servicio: es un producto que ofrece la empresa CEMOSA a clientes, en el marco del TFG, un servicio es un ensayo que se la hace a la muestra. Actores:  Participantes: son las partes que no interactúan con el sistema de forma directa, pero son necesarios para su funcionamiento. Los participantes en el caso del TFG son:  Operadores de laboratorio que hacen la toma de muestra y rellenan los albaranes que recogen la información de la muestra, en adelante serán denominados operadores de muestras.  Operadores de laboratorio que realizan los ensayos y rellenan los borradores con los resultados, en adelante serán denominados operadores de ensayos.  Interlocutores del expediente de la muestra que pueden ser el fabricante de la muestra, empresa constructora, CEMOSA, cliente, contratista.  Usuarios: los usuarios son los participantes que hacen uso directo del sistema que se va a crear, principalmente son los técnicos que introducen los datos de las muestras y los resultados de los ensayos recopilados desde los borradores. En adelante, a este perfil se denominara como técnicos de laboratorio. 39 3.2. Requisitos funcionales Los requisitos funcionales determinan el funcionamiento del sistema y cómo interactúa con su entorno, también define los estados que puede tener. A continuación se resumen los requisitos que deben reflejarse en el funcionamiento final del sistema: Requisito general: RF-1 Gestión de datos de una muestra Descripción Gestión de datos de muestras Requisitos específicos RF-1.1 Añadir los siguientes campos específicos de morteros a la pantalla general de entrada de muestras:  Tipo de mortero  Uso previsto  Tipo cemento  Matrícula del camión  Planta  Contenido de cemento  Relación Agua/cemento  Hora de toma  Hora fabricación de probetas RF-1.2 Asignación de servicios RF-1.3 Asignación de informe a la muestra RF-1.4 Asignación de borrador a la muestra Especificaciones y puntos de verificación  Creación de nuevas muestras de morteros  Modificación de datos muestras de morteros Requisito general: RF-2 Gestión de resultados de ensayos Descripción Operación CRUD sobre datos de resultados recogidos de borradores después de la realización de los ensayos. Requisitos específicos RF-2.1 Introducir y modificar datos de ensayos de una muestra RF-2.2 Guardar datos de ensayos de una muestra RF-2.3 Guardar datos de auditoría, básicamente hay que guardar quién ha creado o modificado los datos y cuándo. RF-2.4 Mensajes en pantalla indicando corrección de cálculos o fallo y su causa. RF-2.5 Generación de informe de morteros a partir de la pantalla de resultados con todos los resultados. 40 Especificaciones y puntos de verificación Los ensayos a gestionar son los siguientes: 1. Absorción de agua por capilaridad 2. Resistencia a la adhesión 3. Densidad aparente 4. Contenido en cloruros 5. Resistencia a la compresión y flexión 6. Consistencia 7. Aire ocluido Requisito general: RF-3 Borradores Descripción Generación de borradores de laboratorio con los campos y tablas donde se puedan rellenar las mediciones y resultados de ensayos Requisitos específicos RF-3.1 Generación de borrador con los ensayos a realizar RF-3.2 Los ensayos deben poder agruparse para optimizar espacio en la impresión o bien poner cada ensayo en una página Requisito general: RF-4 Informes Descripción Generación de informe con los datos de la muestra y los resultados de los ensayos. Requisitos específicos RF-4.1 Creación de informe para morteros de albañilería RF-4.2 Creación de informe para morteros de revoco Requisito general: RF-5 Listados de resultados Descripción Creación de una nueva transacción para generar un listado con los resultados de los ensayos de una o más muestras de morteros. Requisito general: RF-6 Correos de correspondencias Descripción Se debe poder mandar un correo a los interlocutores de una muestra con el informe adjuntado Requisitos específicos RF-6.1 Añadir tabla en formato HTML con un resumen de los resultados de los ensayos al cuerpo del mensaje 41 3.3. Requisitos no funcionales Los requisitos no funcionales para el CCM, son iguales para cualquier otro material para el que se usa SAP como herramienta de soporte de control de calidad, estos requisitos ha sido impuestos por el jefe desarrollo para que el CCM también tenga la misma estructura y diseño usada en el departamento para cualquier proyecto de personalización de SAP. Los requisitos funcionales mas importantes se resumen a continuación:  RNF-1: los borradores deben contener una información básica de los datos de la muestra y la norma que especifica el ensayo.  RNF-2 los borradores y las pantallas de entrada de resultados deben ser lo más parecidos posible.  RNF-3: aprovechar espacio en borradores para ahorrar en papel de impresión.  RNF-4: los informes se guardan en el sistema con sus datos para poder consultarlos en cualquier momento  RNF-5: los informes y su contenido deben cumplir con la normativa.  RNF-6: Integrar la entrada de muestras del mortero en la pantalla de entradas general ZLEM0 adaptando funcionalidades de otros materiales si hace falta.  RNF-7: Los borradores deben contener las unidades de medida escritas en cualquier campo que el operador de ensayos vaya a rellenar para no crear ninguna confusión o errores. 3.4. Casos de uso Permiten identificar las posibilidades de interacción entre el sistema y los actores usuarios, es decir todas las funciones que deben prestarse por el sistema. También sirven para delimitar el sistema y saber que es lo que hace y lo que no hace. Los principales componentes de un diagrama de uso son los actores, y los casos de uso. Un actor representa un elemento externo que interactúa con el sistema. Este elemento puede ser un usuario o un sistema (otro ordenador, otro programa, base de datos). La ilustración 19 muestra este diagrama, en el que identificamos ocho casos de uso. Las relaciones con flechas discontinuas que están marcadas con la etiqueta <<include>> significan que el caso origen es dependiente de la realización del caso de destino, Mientras que las etiquetas <<extend>> se refieren a que los casos de origen son extensiones que se pueden hacer a partir del caso destino de la relación. 48 Ilustración 25 UC6 - Diagrama de secuencia de generación del informe 49 Ilustración 26 UC7 - Diagrama de secuencia de correo de correspondencias Ilustración 27 UC8 - Diagrama de secuencia de generación de listado 50 3.6. Diseño La fase de diseño es el proceso con el que se pretende definir todos los detalles del sistema que permitirán luego su implementación de forma precisa de otros aspectos del sistema como el modelo de datos, controladores. Al analizar todos los requisitos se ha estructurado el transversal de laboratorio para el control de morteros en diferentes programas, grupos de funciones, pantallas y subrutinas:  Modificación del programa de entrada de muestras general para responder a eventos de los nuevos campos de mortero añadidos a la interfaz. Esto responde a los requisitos RF-1.1, RF-1.2 Y RNF-6.  Crear grupo de funciones específico de morteros, en el que existan varias funciones para la obtención, guardado o calculo de datos de ensayo de morteros, esto responde a los requisitos RF-2.2, RF-2.3 y RF-2.4.  Crear pantallas en el Modulpool de entrada de resultados del grupo 4 al que pertenece el mortero, con esta parte se responde a los requisitos RF-2.1 y RNF-2.  Crear un programa nuevo del tipo REPORT, para la obtención de listados de resultados de muestras de morteros usando varios criterios de búsqueda de muestras. Esta parte responde al requisito RF-5.  Crear el borrador usando la tecnología de ADOBE, para ello se necesita crear también un grupo de funciones que hace el rol de una interfaz de comunicación entre SAP y ADOBE. Esta parte responde a los requisitos RF-3.2 de forma explicita, y de manera implícita, al tener borrador creado, modificando tablas de parametrización los requisitos siguientes se cumplen también RF-1.4, RF-3.1, RNF-1, RNF-2, RNF-3, RNF-7.  Crear informes para dos tipos de morteros, de tipo Microsoft Word, con los resultados usando una herramienta en SAP de conexión con Office. También se debe crear un grupo de funciones para poder recuperar los datos de la muestra y sus ensayos para escribirlos automáticamente en el informe. Esta parte responde a los requisitos siguientes: RF-4.1, RF4.2, RF-2.5. Implícitamente y después de la parametrización de tablas de configuración se cumplen los requisitos RF-1.3, RF-2.5, RNF-5.  Crear de módulos de funciones en el grupo de funciones general a todos los materiales que se encarga de crear los correos, estos módulos de funciones se encargan de generar el correo con la tabla en HTML en el cuerpo, y adjuntan el informe al correo. Esta parte responde al requisito RF-6 en general. 51 Para poder hacer el modelo de datos de forma precisa, se ha empezado con el diseño prototipos de pantallas de entrada de muestras y de entrada de resultados, ya que son la base de todos los demás requisitos y siendo los puntos de entrada de datos por parte del usuario. 3.6.1. Entrada muestras Como se ha especificado anteriormente, se debe adaptar la pantalla de entrada de muestras general por la que se introducen datos de muestras de otros materiales que no tienen su propia pantalla, añadiendo los campos detallados en RF-1.1 y la lógica con ABAP para controlarlos. El programa que se debe modificar es el llamado ZLBM_EMGRAL. El proceso que se sigue para le gestión de muestras en general se detalla en el diagrama de flujo en la ilustración 28, donde se ven las funciones que tiene el usuario para gestionar muestras. La ilustración 29 muestra la pantalla con los nuevos campos de morteros marcados en rojo, y luego se detallan los datos añadidos. En esta fase del desarrollo se han creado las interfaces junto con los campos que no existían en las tablas del diccionario de datos para guardar los nuevos datos, quedando la tarea de añadir código de control a la fase de implementación. Esta manera de trabajo es debida a que el cambio en pantallas es bastante fácil usando la herramienta de diseño de pantallas llamada Screen Painter que ofrece funciones de Drag&Drop, también es fácil el cambio en el diccionario de datos ya que proporciona una interfaz grafica para ello, mientras que el cambio en el código es mas difícil y conlleva mas análisis de impacto. Por lo que se ha dejado para la fase de implementación para asegurarse de tener un diseño correcto y aprobado por la parte del jefe de desarrollo. Ilustración 28 Diagrama de flujo de entrada de muestras 52 Ilustración 29 Entrada de muestras general modificada Los nuevos campos de mortero se deben guardar en una tabla llamada ZTLB_MUSTRAS donde se guardan todos los datos de cualquier muestra independientemente del material, su clave primaria es el id de muestra, por lo que el numero de campos que contiene es mayor, 162 columnas, esta tabla se relaciona con muchas otras tablas más mediante claves foráneas y representa un punto de intersección de varios módulos del ERP como gestión de proyectos, gestión de operaciones y gestión de clientes, etc. Los campos de morteros existen ya como columnas de la tabla de muestra porque otros materiales tenían estos campos de entrada en otras pantallas, así que se ha aprovechado para no crear redundancia en el diccionario de datos, la tabla siguiente relaciona cada campo de morteros con la columna de ZTLB_MUESTRAS a la que corresponde. 53 Tabla 1 Campos de mortero con las columnas donde se guardan Campo en pantalla Campo en diccionario de datos Tipo de cemento ZTLB_MUESTRAS-IDTIPOCEM Uso previsto ZTLB_MUESTRAS-USOPREVISTO Fabricante ZTLB_MUESTRAS-FABRICANTE Planta ZTLB_MUESTRAS-IDPLANTA Matrícula del camión ZTLB_MUESTRAS-MATCAMION Cantidad de cemento ZTLB_MUESTRAS-CANTCEM Relación Agua/Cemento ZTLB_MUESTRAS-AC Hora de fabricación de probetas ZTLB_MUESTRAS-HOFAB Hora de toma ZTLB_MUESTRAS-HOTOMA 3.6.2. Entrada de resultados El programa de entrada de resultados para el grupo 4 al que pertenece mortero ya existe dado que existen ya pantallas de otros materiales que pertenecen a este grupo. El programa se llama ZLBM_ERGR4. Las pantallas de entrada de resultados con que interactúan los usuarios se dividen en grupos de campos que separan los datos según su contexto en el proceso, en general hay datos de cabecera, datos previos (opcional), datos de ensayos y datos de auditoria. Igual que en la entrada de muestras en esta fase primero se han desarrollado las pantallas con el Screen Painter, también se han creado las tablas de base de datos y estructuras correspondientes que darán soporte de almacenamiento de los datos de resultados y control en el código ABAP. La estructura de los apartados que vienen a continuación se ha organizado explicando cada ensayo aparte, empezando con los detalles del ensayo analizados del documento de la norma, luego se muestra la captura del documento desde el cual se han deducido las pautas para el diseño del ensayo, también se ilustra la pantalla diseñada junto al modelo de datos. Antes de entrar en los detalles de los ensayos, es importante explicar detalles del modelo de dominio 7 de la base de datos del laboratorio mostrando parte de las tablas más importantes que ya existen y con los que se van a relacionar las nuevas tablas de los ensayos del mortero. La ilustración 30 muestra este el modelo de dominio. La tabla de ensayo en el modelo de dominio representa las tablas que vamos a ir creando durante los apartados que vienen por cada ensayo. Las tablas servicio y muestra están representados en el modelo de datos por dos tablas muy importantes son ZTLB_MURELSER y ZTLB_MUESTRAS, la primera guarda información relacionando una muestra con los servicios que tiene 7 El Modelo de Dominio es una diagrama que representa a un alto nivel de abstracción la relación entre los objetos que forman parte del negocio. 54 asociados mientras que la segunda guarda información de las muestras. La ilustración 31 muestra estas dos tablas junto con sus claves primarias 8 . Ilustración 30 Porción del modelo de dominio del laboratorio Ilustración 31 Tabla de muestras y la tabla que relaciona muestras con los servicios 8 El campo mandt es un campo que siempre se debe de poner a las tablas como clave primaria, su funcionamiento es interno a SAP y queda fuera del ámbito del TFG. 55 1) Absorción de agua por capilaridad (UNE-EN 1015-18) Se fabrican seis probetas 9 y al cabo de 28 días desde la fecha de su fabricación, se inicia el ensayo con los pasos siguientes:  Se pesan las probetas antes de sumergirlas en agua, y se apunta la hora y el peso inicial en el borrador, y se sumergen en agua.  Al cabo de 10 minutos, se secan las probetas, se pesan y se apunta el peso con la hora en el borrador, y rápidamente se vuelven a sumergir en agua.  Al cabo de 90 minutos, se sacan las probetas y se pesan, se apunta el peso con la hora en el borrado. El coeficiente de absorción de agua por capilaridad es la media aritmética de los coeficientes intermedios de cada probeta. El coeficiente de absorción se calcula mediante la formula siguiente: La ilustración 32 muestra una captura del Excel que detalla este ensayo. Además el Excel contiene los valores de precisión en decimales que se deben tener en cuenta en el momento de hacer los cálculos. A partir de estos datos se ha decidido usar dos tablas en la base de datos llamadas ZTLB_MOABSORCION y ZTLB_MOMEDABS, en la primera se guardan los datos de las probetas y en la segunda se guardan los datos genéricos al ensayo como las horas, edad y la media además en ambas tablas se añaden campos de auditoria para guardar los datos de la fecha y el personal que ha hecho la modificación. La ilustración 33 muestra la pantalla por donde los usuarios introducen los datos del ensayo y La ilustración 34 muestra el modelo de datos representando este ensayo. 9 Una probeta es una pieza de secciones circulares o cuadrados, fabricada de una porción de la muestra C = 0,1 (P2 – P1) Kg/(m2.min0,5) P1: masa de probeta después de una inmersión de 10 min P2: masa de probeta después de una inmersión de 90 min C: coeficiente de capilaridad 56 Ilustración 32 Ensayo de absorción de agua Ilustración 33 modelo de datos del ensayo de absorción . 57 Ilustración 34 Pantalla del ensayo de absorción de agua 2) Densidad aparente (UNE-EN 1015-10) En este ensayo se fabrican tres probetas en un molde de un volumen fijo de 256x10-6 m3. Se pesan las probetas y se anota el peso en el borrador. La densidad aparente de la muestra se calculo mediante la media aritmética de los valores intermedios que se calcula dividiendo el peso entre el volumen fijo. Igual que en el ensayo de absorción, se ha usado el Excel, ilustración 35, para diseñar el modelo de datos presentado en la ilustración 36 y la pantalla de entrada del ensayo en la ilustración 37. El modelo de datos se compone también como en absorción de dos tablas que tienen una relación de uno a mucho, ya que una almacena los datos de mediciones de probetas, y la otra es general al ensayo conteniendo la media. Ilustración 35 Ensayo de densidad aparente 64  ZTLB_ROTURAS donde se guardan las medias aritméticas de las probetas que se han roto a una edad y que corresponden a un tipo de fuerza de rotura, se han añadido campos para guardar la media de las unidades de tensión que no tenía.  ZTLB_PROBETAS que contiene, los datos de rotura de cada probeta. Ilustración 47 Excel de ensayo de flexión y compresión Ilustración 48 Modelo de datos del ensayo de resistencia a la flexión y compresión 65 Ilustración 49 pantalla de ensayo de resistencia a flexión y compresión 3.6.3. Borradores Para el la creación de los borradores se ha usado un programa que enlaza SAP Workbench con ADOBE Livecycle y al que se accede ejecutando la transacción SFP. Dentro de este programa se accede a un conjunto de funcionalidades que permiten diseñar documentos de tipo PDF como acciones de DRAG&DROP de elementos, enlace directo con objetos del diccionario de datos o bien posibilidad de dinámicamente manipular el contenido del documento con el lenguaje de JavaScript o FormCalc 10 . El desarrollo de esta tarea ha pasado por las siguientes tareas que se detallan en la parte de implementación:  Crear las estructuras de datos y las tablas necesarias en el diccionario de datos para enlazar el borrador con las tablas de los ensayos diseñadas en el apartado anterior, de manera que el borrador tenga una estructura similar a la de la pantalla.  Diseñar el documento usando la herramienta de LiveCycle. 10 Lenguajes integrados dentro de Livecycle para la manipulación del contenido del PDF, por ejemplo esconder un elemento o mostrarlo según una condición. 66  Creación de módulos de funciones para crear los objetos que representen instancias de las tablas de los ensayos e inicializar datos por defecto como numero de probetas para luego pasarlos por parámetro al programa para usarlos dentro del PDF. Dentro de estos grupos de funciones estarán las funciones que representan el enlace concreto entre ADOBE y SAP usando código ABAP. 3.6.4. Informes En esta tarea se usara un programa, llamado ZGC_PLANTILLAS, que ofrece un enlace dentro de SAP con Microsoft Word, de manera que la mayoría de las ediciones que se puedan hacer a un documento tipo Word se pueden hacer dentro de SAP. Para poder mostrar datos del diccionario de datos dentro del fichero Word, igual que en el borrador, habrá que crear tablas y estructuras de la base de datos, que se usaran para mostrar los resultados en el informe, la diferencia con el borrador es que en el informe deben aparecer las tablas rellenadas con los resultados obtenidos. Entonces las fases de esta tarea son las siguientes:  Preparación del fichero Word antes de integrarlo dentro de SAP añadiendo al documento propiedades que serán campos donde se insertan los valores de los ensayos.  Subir el documento a SAP y parametrizar las tablas necesarias para que se pueda usar en el programa de edición de ficheros Word.  Enlazar las propiedades creadas en el fichero Word con sentencias SAP llamadas formulas que relacionan una propiedad del fichero Word con una sentencia de select dentro del código ABAP que se encarga de traer los datos y insertarlos en la propiedad de Word.  Crear el grupo de funciones que enlace instancia las tablas y estructuras y recupere los datos de la base de datos para mostrarlas en el informe. 3.6.5. Listado de resultados En esta fase se deben crear un programa de tipo REPORT que le de al usuario la posibilidad de ver un listado de los datos de todos los ensayos usando lo que se llama en SAP ALV por sus siglas ABAP List Viewer, este listado es parecido a una vista de la base de datos que agrupa varias columnas de diferentes tabas de la base de datos usando una estructura preparado con todos los campos que se quieran mostrar. Los ALVs ofrecen varias funcionalidades para trabajar con listados, ilustración 50, entre ellas encontramos ordenar datos usando uno o mas campos de forma ascendente o descendente, uso de filtros avanzados para buscar datos, elegir las columnas que se quieran mostrar y finalmente y muy importante la opción de exportar los datos a un Excel o a Word. Para esta parte del desarrollo se han hecho las siguientes tareas que se detallan en el capitulo de implementación: 67  Creación de un programa de tipo REPORT con una transacción específica para materiales de morteros, que generen los listados según los parámetros de búsqueda de muestras que quiera el usuario.  Creación del grupo de funciones que de soporte al programa anterior para trabajar de forma modular. Además este grupo de funciones forma un punto de intersección con el programa del informe y el programa que genera el correo, ya que se aprovecha la función que hace un select a la base de datos para recuperar todos los datos de los resultados y los datos de la muestra para generar el listado, para recuperar los datos para añadirlos al cuerpo del correo y para añadirlos al informe. Ilustración 50 Funcionalidades del ALV 3.6.6. Correo de correspondencias En esta tarea se pretende diseñar con código HTML incrustado dentro del código ABAP una tabla que se inserta dentro del cuerpo del correo que se le manda a los interlocutores, esta función puede parecer redundante ya que en el mismo correo se adjunta el informe que contiene todos los resultados y con detalle, pero es una mejora que ha decidido el departamento de informática añadir para mejorar los servicios que ofrece a la propia empresa CEMOSA y a los clientes, ya que algunos informes ocupan mucho espacio y si algún interlocutor esta en un móvil o no tiene acceso a una buena conexión (3G por ejemplo), pues con esta mejora va a poder ver los resultados de los ensayos de forma compacta dentro del cuerpo del correo. Para el desarrollo de esta tarea se debe añadir nuevos módulos de función y subrutinas al programa que ya existe y que gestiona el envío de correos a los interlocutores. 68 4. Implementación En esta fase se explica todos los detalles relacionados con la implementación del sistema diseñado mediante el análisis del capítulo anterior, se proporcionan varias capturas explicando el desarrollo además de pantallas de código. Los apartados de este capitulo se han ordenado primero según la prioridad, por ejemplo la creación de los elementos del diccionario de datos es necesario para cualquiera de los otros apartados, luego el orden es según si existe una intersección entre programas, por ejemplo los informes vienen después de los listados ALV ya que el informe obtiene datos de la librería (grupo de funciones) desarrollado para dar soporte a la generación de listados. Antes de iniciar con los detalles de la implementación, hay que detallar el concepto de Dynpro, ya que son un elemento muy importante en todo el desarrollo. Las dynpros son pantallas interactivas que hacen el rol de interfaz grafica de usuario y expone al usuario elementos como campos (solo de salida, de entrada y salida), áreas de texto, botones, menús, pestañas, tablas, etc. El usuario puede interactuar con estos elementos causando el disparo de eventos. Ante cualquier evento, se ejecuta el código de control de la dynpro, que se identifica mediante un código de función que asocia el elemento con el código usando una variable del sistema llamada SY-UCOMM, por ejemplo al hacer clic en guardar, el SY-UCOMM contendrá el valor ‘SAVE’, de esta manera dentro del código de control se puede crear funciones que se encargan de la tarea de respaldo en la base de datos. Las pantallas contienen elementos estándar que tienen OKCODE ya asociados, pero el usuario puede asignar a los elementos que vaya creando, un código de función para crear un comportamiento personalizado en la pantalla. Los dynpros forman parte de los componentes de los programas llamados Modulpools, que se ejecutan mediante la creación de una transacción que les identifica de forma unívoca en todo el sistema. Los Modulpools se estructuran de manera que se juntan todos los elementos que son del mismo tipo en el mismo grupo como se ve en la ilustración 51. Cada dynpro, normalmente tiene dos secciones de código que corresponden, que se ejecutan de forma separada:  PBO: de sus siglas Process Before Output, es la parte del código ABAP que se ejecuta siempre antes de mostrar la pantalla al usuario. En esta parte del controlador suelen estar funciones de inicialización de datos (select a base de datos, formateo) y actualización de campos de la pantalla de usuario, además de cualquier otra operación que el desarrollador estime oportuna antes de rendir el grafico al usuario. 69  PAI: de sus siglas Process After Input, es la parte del código ABAP que se ejecuta siempre que ocurra un evento dentro de la pantalla. En esta parte el usuario define todas las funciones que corresponden al evento disparado por el usuario, por ejemplo guardado de datos, cálculo de resultados o cierre de pantalla, etc. Cada proceso tiene uno o varios modules asociados con él, que son funciones que se ejecutan según donde estén situados dentro del proceso de control y que representan la acción a ejecutar tras el disparo de un evento. La ilustración 52 muestra algunos modules y su funcionamiento. Ilustración 51 Estructura de un ModulPool 70 Ilustración 52 Modules de procesos y su funcionamiento 4.1. Diccionario de datos En este apartado se exponen las tablas, estructuras, elementos de datos, etc. creado para dar soporte a todos los nuevos componentes. Se ha divido este apartado según el tipo de elemento de diccionario de datos. Se proporcionan ilustraciones que demuestran la implementación. 4.1.1. Tablas Entrada de muestras Como se había indicado en la fase de análisis y diseño, para el la entrada de muestras no se van a crear tablas, sino se usaran campos que ya tiene que se corresponden con los campos nuevos de mortero excepto el campo de uso de mortero, que para su guardado se usara él de otra tabla llamada 71 ZTLB_USOARIDOS que contiene los campos de la ilustración 53. La clave primaria es un número que identifica el uso y un campo de texto que describe el uso. Para no crear tablas innecesarias en el diccionario de datos, se ha decidido el uso de esta tabla después de analizar todos los programas en que se usa y el modo en que se usa. Esta tabla se usaba solo el material de áridos, por lo que en las dynpros en que había que introducir el campo de uso de áridos, el sistema ofrecía al usuario una lista con los registros de esta tabla sin ninguna condición sobre el select que devuelve el listado. Para adaptar esta tabla a cualquier material y reutilizarla, se ha creado una tabla nueva que relaciona el tipo de material con el uso. La ilustración 54 muestra el modelo de dominio diseñado para este caso mostrando una relación de muchos a muchos entre los materiales y los usos, que se concretiza usando una nueva tabla llamada ZTLB_USOMATERIAL que se muestra su especificación en el diccionario en la ilustración 55 conteniendo una clave del tipo de material junto con la clave del uso. Ilustración 53 Tabla de ZTLB_USOARIDOS Ilustración 54 Modelo de dominio que representa la relación MATERIAL-USO 72 Ilustración 55 Tabla que relaciona materiales con los usos, ZTLB_USOMATERIAL Ahora que se han creado las tablas, se debe crear una ayuda de búsqueda. La ayuda de búsqueda es una funcionalidad muy potente que ofrece a los usuarios de SAP la posibilidad de realizar una selección y filtro de datos según los parámetros de entrada que quieran, permiten también el filtro usando expresiones regulares. Para definir una ayuda de búsqueda personalizada, se debe identificar la tabla origen de la que se hace la selección, los parámetros que se deben mostrar y con los que se puede buscar, y ya SAP se encarga de hacer las consultas necesarias para mostrar los datos. Si los desarrolladores necesiten cambiar la forma en se hacen las consultas para cargar los datos, las ayudas de búsqueda permiten definir una función llamada Exit function que se ejecuta siempre que se dispare el evento de búsqueda sobre el campo que se define. Para el caso de uso de materiales, vamos a usar las funciones de salida (Exit Function), ya que necesitamos hacer select con un join de la tabla ZTLB_USOARIDOS donde se guardan los textos de uso y sus identificadores y la tabla ZTLB_USOMATERIAL. Las ilustraciones siguientes muestras los pasos seguidos para la creación de la nueva ayuda de búsqueda Ilustración 56 Creación de ayuda de búsqueda en el diccionario y asociarla con la función de salida 73 Las funciones de salida de las ayudas de búsqueda se crean en un grupo de funciones específico de esta utilidad y esta creado por el equipo de desarrollo. El código 1 siguiente forma el código fuente dentro del modulo de función Z_LB_SHLP_USOPREVISTO donde se hace el select con el join, no se detalla todo el código ya que gran parte de ese es generada automáticamente por SAP. La parte del código marcada en gris representa el select, y una instrucción que obtiene el valor del material desde un parámetro de la memoria. Los parámetros de memoria son una manera de intercambiar variables entre programas sin que se hagan llamadas explicitas de funciones de forma que un programa guarda con la sentencia SET parameter ID el valor del parámetro en memoria, en este caso se llama ZTIPO, y desde ese momento cualquier otro programa y mientras el usuario no cierre la sesión o que otro programa borre el parámetro, ese valor es accesible en todos los programas de SAP. 80 Ilustración 63 Estructura profunda con datos generales y una lista de mediciones Para el listado de ALV se ha creado una estructura llamada ZSLB_MORTEROS, que contiene 52 campos, que representan el conjunto de todos los campos de resultados y datos de muestras de morteros. Sabiendo que el listado AVL es un conjunto de registros que tienen la misma estructura pues se ha creado un tipo tabla llamado ZSTLB_MORTEROS que se va a usar como tipo de la variable de salida del modulo de función que obtiene el listado de resultados. Igual que para los ALV se ha creado una estructura para el informe llamada ZSLB_INFORMEMORTEROS que contiene un subconjunto de la estructura del listado AVL ya que el informe solo contiene los datos que impone la norma, mientras el listado es para la empresa CEMOSA que debe tener todos los datos relacionados con alguna muestra. 81 4.2. Entrada de muestras El programa de tipo ModulPool de entrada de muestras ya existe, ZLBM_EMGRAL, por lo que se le ha agregado código de control para los nuevos campos de mortero. Específicamente se ha añadido código al proceso PAI que entra en ejecución tras un evento en la pantalla, el código añadido en el PAI es un nuevo module para responder al evento de hacer clic en entrar después de cambiar un campo de mortero en pantalla. El código es el siguiente: "-->10849 - Comprobar uso previsto de material chain. field ztlb_muestras-usoprevisto. field ztlb_muestras-idplanta. field ztlb_muestras-idtipocem. module pai_9000_camposmorlech on chain-request. endchain. "<--10849 Código 2 Module de entrada de muestras El module añadido es el pai_9000_camposmorlech y su código es el siguiente: *&-------------------------------------------------------------------- -* *& Module PAI_9000_CAMPOSMORLECH INPUT *&-------------------------------------------------------------------- -* * Autor YAO4050 - 10849 - 20/09/2016 * text Controla el cambio de los campos añadidos para entrada s * de morteros y lechadas de inyección (planta, tipo ceme nto, * matrícula y uso previsto) *--------------------------------------------------------------------- -* module pai_9000_camposmorlech input. perform f_cargar_usoprevisto. perform f_cargar_planta. perform f_cargar_tipocemento. endmodule. " PAI_9000_CAMPOSMORLECH INPUT Código 3 Module de modificación de campos mortero El código anterior llama a tres funciones auxiliares mediante la llamada PERFORM dentro de esas funciones se hace el recupero de los valores de texto de los campos que se ha introducido sus identificadores en la pantalla, ya que en la pantalla no se busca el identificador y dentro de código de proceso se recupera el valor textual de la tabla correspondientes de la base de datos. Los códigos son los siguientes: 82 *&-------------------------------------------------------------------- -* *& Form F_CARGAR_USOPREVISTO *&-------------------------------------------------------------------- -* * Autor YAO4050 - 10849 - 20/09/2016 * text Carga la descripción del uso previsto si existe *--------------------------------------------------------------------- -* * --> p1 text * <-- p2 text *--------------------------------------------------------------------- -* form f_cargar_usoprevisto . data: wl_descripcion type ze_uarido. if t_muestras-usoprevisto <> ztlb_muestrasusoprevisto. "Si se ha producido cambio, "se entra en la ejecución. select single usoarido from ztlb_usoaridos into wl_descripcion where idusoarido = ztlb_muestras-usoprevisto. if sy-subrc <> 0. clear wl_descripcion. clear ztlb_muestras-usoprevisto. endif. t_muestras-usoprevisto = ztlb_muestras-usoprevisto. salida_usoprevisto = wl_descripcion. endif. endform. " F_CARGAR_USOPREVISTO Código 4 Obtener descripción de uso del material 83 *&-------------------------------------------------------------------- -* *& Form F_CARGAR_PLANTA *&-------------------------------------------------------------------- -* * Autor YAO4050 - 10849 - 20/09/2016 * text Carga el nombre de la planta si existe *--------------------------------------------------------------------- -* * --> p1 text * <-- p2 text *--------------------------------------------------------------------- -* form f_cargar_planta . if t_muestras-idplanta <> ztlb_muestrasidplanta. "Si se ha producido cambio, "se entra en la ejecución. select single * from ztlb_plantas where idplanta = ztlb_muestras-idplanta. if sy-subrc <> 0. clear ztlb_muestras-idplanta. endif. t_muestras-idplanta = ztlb_muestras-idplanta. endif. endform. " F_CARGAR_PLANTA Código 5 Obtener el nombre de la planta 84 *&-------------------------------------------------------------------- -* *& Form F_CARGAR_TIPOCEMENTO *&-------------------------------------------------------------------- -* * Autor YAO4050 - 10849 - 20/09/2016 * text Carga la descripción del cemento si existe *--------------------------------------------------------------------- -* * --> p1 text * <-- p2 text *--------------------------------------------------------------------- -* form f_cargar_tipocemento . data: wl_descripcion type ze_desig_cem_lib. "Si se ha producido cambio, se entra en la ejecución. if t_muestras-idtipocem <> ztlb_muestras-idtipocem. select single decripcion from ztlb_cementos into wl_descripcion where idtipocem eq ztlb_muestras-idtipocem. if sy-subrc <> 0. "Si no existe se borra el valor introducido clear wl_descripcion. clear ztlb_muestras-idtipocem. endif. t_muestras-idtipocem = ztlb_muestras-idtipocem. ztlb_muestras-desig_cem_lib = wl_descripcion. endif. endform. " F_CARGAR_TIPOCEMENTO Código 6 Obtener el texto de tipo de cemento 4.3. Entrada de resultados El desarrollo de la entrada de resultados es la parte que más tiempo ha llevado y que es más extensa, pero es repetitiva, ya que las mismas tareas se tienen que realizar para cada ensayo. A continuación detallamos todo el código creado para la entrada de resultados del ensayo de absorción de agua que representa el control con ABAP de la pantalla presentada en la ilustración 34, que contiene las mismas funcionalidades creadas, pero adaptadas con diferentes tablas y estructuras, para los demás ensayos. Por la extensión del código de este apartado se han hecho capturas de pantalla de trozos del código estratégicamente elegidas de manera que las ilustraciones muestren el flujo que sigue el código. La pantalla creada para el ensayo de absorción es la 9012, ya que el programa ZLBM_ERGR4 contenía ya pantallas de entrada de resultados de otros materiales que pertenecen al mismo grupo que el mortero. Por convención las 85 pantallas no estándar de SAP, se numeran a partir del 9000, mientras los de SAP empiezan en 1000. Antes de empezar a explicar el programa de entrada de resultados, hay que presentar el grupo de funciones que se ha creado para dar soporte a todos los ensayos, de manera que contenga todas las funcionalidades de obtención de datos mediante consultas a la base de datos, también se encarga de realizar los cálculos y guardar los datos en la base de datos. El grupo de funciones se ha llamado ZFGLB_ERGR4, la ilustración 64 muestra la mayoría de los módulos de función creados. Estos módulos hacen llamadas a otros que ya existían en el sistema por ejemplo para guardar datos de auditoria en la estructura incluida en cada tabla para este fin. En la ilustración se han marcado los módulos de carga, calculo y guardado del ensayo de absorción. Ilustración 64 Grupo de funciones de ensayos de mortero 4.3.1. Módulo PBO Como ya hemos comentado antes, el pbo es donde se hacen las acciones que se deben ejecutar antes de rendir el grafico al usuario. Para la pantalla de absorción se ha creado una ICLUDE que es un paquete que contiene funciones que pertenecen al mismo proceso de ejecución, llamado ZLBM_ERGR4_PBO_12. En este include van todos los modules que se ejecutan en el PBO de manera que se pare el código según la lógica a la que corresponda, de esta manera el mantenimiento es mas ágil ya que el código es fácilmente localizable. 86 En este proceso de ejecución se hace la inicialización de los datos generales de la pantalla y se cargan los datos del ensayo, para que si ya existen entradas pues el usuario pueda verlos y modificarlos si quiere, sino las entradas salen vacías. El código 7 muestra el código del PBO y las funciones que ejecuta la parte mas importante es la función inicializar_datos_9012 que es parte encargada de hacer una llamada al modulo de función que carga los datos de la base de datos. Código 7 Proceso de carga de datos del ensayo de absorción 4.3.2. Módulo PAI En esta parte de la ejecución del control de la Dynpro se realizan las acciones que responden a los eventos disparados por una acción del usuario. En el menú de las pantallas diseñadas para las entrada de resultados de ensayos, las funcionalidades mas importantes que se ha desarrollado son las de guardado de datos y de cálculo. A partir del código del module llamado user_command_9012 y según el contenido de la variable del sistema sy-ucomm (comando de usuario) se ejecuta alguna funcionalidad usando la estructura de control de flujo de código CASE. El código siguiente muestra el recorrido de ejecuciones para el cálculo y el guardado de los ensayos. 87 Código 8 Gestión de comandos de usuario en el PAI del ensayo de absorción A partir de las funciones de calculo y de guardado se hacen llamadas a los módulos de función encargados de realizar todas estas acciones. A los módulos de función se le pasan las estructuras y tablas que almacenan los datos de los ensayos para mostrarlos en pantalla, se hacen las modificaciones necesarias y se devuelven de nuevo con los datos actualizados. Durante le guardado de datos los datos que se actualizan son los datos de auditoría, mientras que al realizar los cálculos se actualizan los datos relacionados con los resultados y mediciones. Los módulos de función de guardado de datos se dividen en dos módulos de función que guardan las mediciones intermedias y los resultados generales respectivamente. En el código 9 vemos la función que guarda los datos de absorción y que hace llamadas a las dos funciones para guardar los resultados y las mediciones. En el código 10 se muestra cómo se hace el respaldo de las mediciones en la base de datos, en el código se puede ver que no se usan sentencias SQL en claro como ocurre en otras tecnologías como JavaEE, ya que en ABAP se hace la modificación a la base de datos con unas sentencias de alto nivel con una alta abstracción y ya internamente SAP traduce al lenguaje adecuado según el DBMS usado, de esta manera la capa de aplicación es totalmente independiente de la capa de persistencia. Los módulos de función de cálculo incluyen gestión de errores que pueden ocurrir, por ejemplo la división por cero o que un campo debe cumplir una condición como en el caso del peso en ensayo de absorción de agua ya que el peso después de haber sumergido la probeta en agua no puede ser menor o igual a su peso en seco. Para la gestión de mensajes de error se ha usado una variable global al programa de entrada de resultados, y si se detecta un error 88 en el modulo de función, pues esa variable se instancia con mensaje de error adecuado, luego en la parte del programa de donde se ha hecho la llamada a la función, se evalúa si esa variable de error es inicial o no, y se ejecuta la instrucción MESSAGE que se encarga de mostrar en la parte inferior de la pantalla el código de error o éxito de la operación realizada. En el código 11 se muestra la llamada a la función que realiza el cálculo, al disparar el evento de calcular, y en el código 12 se muestra todo el proceso de cálculo de la absorción de agua dentro del módulo de función asignado para este propósito. Código 9 Módulo de función que guarda los datos de todo el ensayo de absorción 89 Código 10 función que guarda las mediciones de absorción en la base de datos Código 11 Llamada de la función para calcular la absorción de agua y mostrar mensaje según valor de variable de errores 96 Ilustración 68 Configuración de borradores en la tabla de materiales 4.5. Listado ALV Para este apartado se ha creado el programa con nombre Z_LIST_MORTEROS que es de tipo REPORT de ALV, y que se ejecuta mediante la transacción ZLIST21, esta transacción se ha añadido a la tabla TSTC mediante la agregación de todos los campos del registro con el campo de nombre programa y dynpro por defecto. El modo de funcionamiento es el siguiente:  Se ejecuta ZLIST21  Se rellenan los parámetros de búsqueda de las muestras de mortero, y se inicia la búsqueda.  El programa cambia a la pantalla de listado con todos los registros del tipo tabla ZSTLB_MORTEROS, si se han encontrado muestras que cumplen con los parámetros de búsqueda se listan sino aparece vacío. Para dar soporte este programa se ha creado el grupo de funciones ZFGLB_LIST_MORTEROS que se encarga de hacer las consultas a la base de datos con todos los parámetros introducidos por el usuario. Un programa que genera un ALV, se compone de una parte de ejecución que se encarga de inicializar los datos, para que si el usuario no introduzca ningún parámetro, se buscan las muestras según unos criterios por defecto que hacen que la consulta no sea demasiado lenta, otra parte de la ejecución del programa se encarga de recuperar las muestras del mortero, en esta parte es donde se hace la llamada al modulo de función que recupera todos los resultados dentro de la estructura mencionado antes. Al final de la ejecución entra la función encargada de listar los datos y mostrar los al usuario. El código desarrollado es el siguiente: 97 *& Report ZLBR_LIST_MORTEROS *& Autor YAO4050 - 10849 - 26/08/2016 *& Text Listado de morteros include zlbr_list_morteros_top. "Declaración de datos globales include zcai_comun_alv_top. " Variables comunes a todos los ALV. include zlbr_list_morteros_sel. include zlbr_list_morteros_f01 . " FORM-Routines include zcai_comun_alv_f01. " Subrutinas comunes ALVs. initialization. perform inicializar. start-of-selection. perform seleccionar. end-of-selection. perform listar. Código 15 Programa REPORT de ALV *& Form SELECCIONAR * Autor YAO4050 - 10849 - 26/08/2016 * Llamada a la función Z_GET_LIST_MORTEROS, pasándole una serie * de parámetros, * y obtención de los resultados a listar form seleccionar . data: tl_rsparams type rsparams_tt. call function 'Z_CA_CAMBIA_TIT_PROGRAMA'. perform f_guardar_rsparams changing tl_rsparams. "cargar parámetros call function 'Z_GET_LIST_MORTEROS' exporting pi_rsparams = tl_rsparams importing pe_listado = t_listado. endform. " SELECCIONAR Código 16 Función de selección, dentro se hace la llamada al la función que devuelve el listado de morteros 98 function z_get_list_morteros. *"*"Interfase local *" IMPORTING *" REFERENCE(PI_RSPARAMS) TYPE RSPARAMS_TT *" EXPORTING *" REFERENCE(PE_LISTADO) TYPE ZSTLB_MORTEROS * Autor YAO4050 - 10849 - 26/08/2016 * Text Cargal el listado de morteros usando la tabla de parámetros * importada. data: li_total type i, "Total de muestras de morteros que cumplen c on los criterios li_cont type i, "Contador para calcular el progreso li_avanz type i. "Contiene progreso de la carga del listado li_avanz = 0. li_cont = 0. “Cargar parámetros en memoria perform f_cargar_parametros using pi_rsparams. “Select de la base de datos perform f_cargar_muestras using pe_listado. describe table pe_listado lines li_total. “Cargar ensayos de la base de datos perform f_carga_tablas_ensayos_memoria using pe_listado. “Asignar datos al listado que se devuelve a programa loop at pe_listado assigning <fs_listado>. perform f_carga_muestra. perform f_carga_operador. perform f_carga_metmuestra. perform f_carga_expediente. perform f_carga_obras. perform f_carga_clientes. perform f_carga_moabsorcion. perform f_carga_modensidad. perform f_carga_moadhesion. perform f_carga_moflexcomp. perform f_carga_moconsistaire. perform f_carga_mocloruros. <fs_listado>-agrupa = 1. perform f_actualiza_progreso changing li_cont li_avanz li_total. endloop. endfunction. Código 17 Módulo de función principal de obtención de todos los resultados de mortero 99 *& Form F_CARGAR_MUESTRAS * Autor YAO4050 - 10849 - 29/08/2016 * text Carga todas las muestras de morteros (ID 44) que cumple n * con los criterios de la selección. form f_cargar_muestras using p_listado type zstlb_morteros. select * into corresponding fields of table p_listado from ztlb_muestras where idlab in s_stort[] and idlib in s_lib[] and ejercicio in s_ej[] and nmuestra in s_nm[] and expediente in s_exped[] and nalbaran in s_alb[] and idmuestra in s_mues[] and fechatoma in s_ft[] and fentrada in s_fen[] and ffinaliza in s_ffi[] and idoperador in s_op[] and fepedido in s_fp[] and pedido in s_pe[] and idtipomaterial = '44' and nmuestra is not null. endform. " F_CARGAR_MUESTRAS Código 18 Select a la tabla de muestras que devuelve todas las que cumplen con los parámetos Como ejemplo de carga de datos los ensayos, se pone el ejemplo del código del ensayo de absorción: *&-------------------------------------------------------------------- -* *& Form F_GET_MOABSORCION *&-------------------------------------------------------------------- -* * Autor YAO4050 - 10849 - 29/08/2016 * text Carga los datos del ensayo de absorción por capilaridad *--------------------------------------------------------------------- -* * -->P_P_LISTADO text *--------------------------------------------------------------------- -* form f_get_moabsorcion using pi_listado type zstlb_morteros. refresh t_moabsorcion. if pi_listado[] is not initial. select * into table t_moabsorcion from ztlb_moabsorcion for all entries in pi_listado where idmuestra = pi_listado-idmuestra. endif. sort t_moabsorcion by idmuestra. endform. " F_GET_MOABSORCION Código 19 Módulo de función que hace un select a la tabla general de absorción 100 *& Form F_CARGA_MOABSORCION * Autor YAO4050 - 10849 - 29/08/2016 * text Asigna datos del ensayo de absorción por capilaridad al listado form f_carga_moabsorcion . field-symbols: <fs_aux> like line of t_moabsorcion. read table t_moabsorcion assigning <fs_aux> with key idmuestra = <fs_listado>-idmuestra binary search. if sy-subrc = 0. <fs_listado>-capilaridad = <fs_aux>-capilaridad. <fs_listado>-hora = <fs_aux>-hora. <fs_listado>-hora10 = <fs_aux>-hora10. <fs_listado>-hora90 = <fs_aux>-hora90. <fs_listado>-edad = <fs_aux>-edad. <fs_listado>-abx = 'X'. endif. endform. " F_CARGA_MOABSORCION Código 20 Ejemplo de asignación de datos de ensayo al listado final 4.6. Informe El departamento de laboratorio ha especificado la necesidad de crear dos tipos de informes de mortero, ya que los ensayos cambian de un tipo mortero a otro por lo que también la normativa impone cambios en los informes, en nuestro caso, se deben crear dos informes, el primero diseñado para cumplir con la normativa de morteros de revoco mientras el segundo es para morteros de albañilería. 4.6.1. Diseño Word Para el diseño de Word, SAP cuenta con un enlace con la tecnología de Office de Microsoft. Para poder diseñar plantillas de informes en Word que luego se usan para mostrar datos desde SAP, se deben seguir unos pasos que se explican a continuación. 1. Diseñar la plantilla en Word en el ordenador local, antes de subir el documento a SAP usando la transacción SCASE que ejecuta un programa que forma parte del modulo de SAP-RM (Record Management) que permite subir, descargar, eliminar y mandar los ficheros subidos a la base de datos de SAP. El fichero debe subirse después de haber creado todas las propiedades que representen campos del fichero Word, y con los cuales se enlazan los parámetros en SAP para pasar los datos. En la ilustración 69 se ha marcado el campo de resistencia a flexión a una edad de catorce días, para mostrar un ejemplo de todo el recorrido por el que pasa un dato para llegar hasta informe final. 101 Ilustración 69 Creación propiedades de Word, se ha marcado el campo de valor de resistencia a flexión a 14 días para dar un ejemplo 2. Una vez subidos los ficheros se deben configurar varias tablas del sistema para poder usar y modificar estas plantillas dentro de SAP. Ahora, se puede acceder desde una transacción llamada ZGC_PLANTILLAS que se encarga de hacer el mantenimiento de ficheros y documentos de plantillas en SAP a un interfaz en el que se puede ver el fichero Word junto a varias tablas de configuración que insertan datos en el documento mediante unas formulas que pueden contener una consulta a la base de datos, o una consulta a una tabla o estructura de un programa. La alternativa no deseable mencionada antes es en la que se usan estas formulas con el código SQL de consulta a la base de datos directamente, por lo que se ha optado por usar un grupo de funciones que contiene una estructura con todos los datos que deben mostrarse en el informe, y se hace la consulta siguiendo la expresión siguiente: SELECT ‘&P_[nombre de campo en la estructura]’. La ilustración 70 muestra como el campo que muestra el valor de la resistencia a la flexión en la edad de catorce días está enlazado con SAP mediante un formula que tiene el mismo nombre que la propiedad creada para ese campo en el fichero Word como lo indica la ilustración 71, además se proporciona la ilustración 72 que muestra parte del contenido de la estructura que contiene todos los datos y que se usan sus campos para asignar valores a los parámetros, en esta 102 última ilustración se ha marcado el campo de flexión a catorce días para tener la imagen completa del funcionamiento. Ilustración 70 Asociar fórmulas con propiedades de Word Ilustración 71 Estructura con todos los datos del informe 103 Además de todo lo anterior, se debe desarrollar el código necesario para obtener los datos, este paso como veremos que no es necesario, ya que se pueden obtener los datos usando otra alternativa pero que no favorece la reusabilidad y no es adecuada en términos de mantenimiento, por lo que se ha optado por desarrollar un grupo de funciones encargado de obtener todos los datos para el informe, este grupo de funciones se explica en el apartado siguiente. 4.6.2. Grupo de funciones Se ha creado un grupo de funciones para las plantillas de mortero, este grupo contiene funciones que recuperan todos los datos necesarios para mostrarlos en el informe final. El grupo de funciones es ZFGLB_DATOSPLANTILLAS3, la función principal que se invoca para generar el informe es Z_LB_PLANTILLA_MORTEROS1 que internamente hace una llamada a la función desarrollada para el ALV llamada Z_GET_LIST_MORTEROS y que devuelve todos los resultados de los ensayos en un tipo tabla de tipo ZSTLB_MORTEROS. Además hace otras llamadas a otras funciones que recuperan contenido necesario para el informe final. Haciendo uso de las funciones desarrolladas en el apartado de listado de ALV, ha ahorrado mucho trabajo de creación de funciones por cada ensayo. La función Z_LB_PLANTILLA_MORTEROS1 tiene muchos parámetros de entrada, que se le pasan desde el programa de entrada de resultados. A continuación detallamos los parámetros de salida de esta función ya que son la clave para la generación de los informes.  PE_DATOS_PLANTILLAS de tipo estructura ZSLB_DATOS_PLANTILLAS, esta estructura se compone de muchísimas mas estructuras que representan, cada una, alguna información destinada a rellenar un tipo de informe con algún dato de ensayo, laboratorio o muestra…. Los campos de estas estructuras son muy importantes, ya que se usaran para hacer el enlace entre Microsoft Word y SAP.  PE_PARAMETROS de tipo SOI_FORM_LIST, son los parámetros que hacen el rol de variables donde se escribe el dato desde SAP y se rellena en el informe en Word. Como se puede apreciar el tipo de esta variable no empieza con Z, por lo que es un tipo estándar. El código 21 muestra como se van añadiendo los datos a esta estructura, haciendo que los nombres de los campos de la estructura ZSLB_DATOS_PLANTILLAS se vayan concatenando con el string ‘P_’ al inicio para luego se haga el select desde la fórmula.  PE_TABLA de tipo ZSTLB_TABLASPLANT, es una tabla usada en el caso en que en el informe se debe generar una tabla con numero de filas de resultados que puede variar, entonces se debe hacer de forma dinámica y que independientemente del número de filas de la tabla en la 104 base de datos, el funcionamiento sea correcto, este caso se da con el ensayo de adhesión que debe ponerse en su informe los resultados intermedios de las probetas además de la media, y como norma general son cinco probetas, pero puede que se hagan mas en algunas circunstancias, para contemplar todos los casos se ha desarrollado añadiendo a la tabla pe_tabla todas las filas, el código 22 muestra el funcionamiento con comentarios explicativos. function z_lb_get_parametros. Interfase local *" IMPORTING *" REFERENCE(PI_DATOS_PLANTILLAS) TYPE ZSLB_DATOS_PLANTILLAS *" REFERENCE(PI_TABLA) TYPE ZSTLB_TABLASPLANT OPTIONAL *" REFERENCE(PI_MUESTRA) TYPE ZE_IDMUESTRA OPTIONAL *" EXPORTING *" REFERENCE(PE_PARAMETROS) TYPE SOI_FORM_LIST data: wa_params type soi_form_item. "Macro para añadir parámetros. define add_params. clear wa_params. wa_params-name = &1. wa_params-value = &2. condense wa_params-value. append wa_params to pe_parametros. end-of-definition. data: tl_campos type table of dd03l. data: wl_campo type string, wl_nombre_parametro type char100. field-symbols: <fs_campos> like line of tl_campos, <fs_valor>. select * from dd03l into table tl_campos where tabname = 'ZSLB_DATOS_PLANTILLAS' and fieldname <> '.INCLUDE'. loop at tl_campos assigning <fs_campos>. clear wl_campo. concatenate 'pi_datos_plantillas-' <fs_campos>- fieldname into wl_campo. assign (wl_campo) to <fs_valor>. if sy-subrc = 0. clear wl_nombre_parametro. concatenate 'P_' <fs_campos>-fieldname into wl_nombre_parametro. add_params wl_nombre_parametro <fs_valor>. endif. endloop. "Borramos el contenido de la tabla temporal para la muestra pasada por parámetro if pi_muestra is not initial. delete from ztlb_tablasplant where idmuestra = pi_muestra. if pi_tabla is not initial. "Insertamos el contenido de la tabla interna en BBDD modify ztlb_tablasplant from table pi_tabla. endif. endif. endfunction. Código 21 Asignación de valores a los parámetros de las formulas 105 function z_lb_get_mor_medadhesion. *"*"Interfase local *" IMPORTING *" REFERENCE(PI_MUESTRA) TYPE ZE_IDMUESTRA *" EXPORTING *" REFERENCE(PE_TABLA) TYPE ZSTLB_TABLASPLANT * Autor YAO4050 - 10849 - 24/10/2016 * Text Obtiene los resultados de mediciones del ensayo de MORT-Adhesión "Cebecera de la tabla de resultados de adhesión types: begin of ty_medadhesion, probeta type ztlb_momedadhes-probeta, superficie type ztlb_momedadhes-superficie, adhesion type ztlb_momedadhes-adhesion, tiporotura type ztlb_momedadhes-tiporotura, end of ty_medadhesion. data: tl_medadh type table of ty_medadhesion,"Tipo tabla para la estructura de cabecera wl_tabla like line of pe_tabla, contador type n. "Se usa para poder concatenar con el string 'muestra' . solo tipos N,C,D,T se pueden concatenar field-symbols: <fs_medadh> like line of tl_medadh."work area para tl_medadh "Select de datos de la BBDD de la tabla ztlb_momedadhes select * into corresponding fields of table tl_medadh from ztlb_momedadhes where idmuestra = pi_muestra order by probeta ascending. loop at tl_medadh assigning <fs_medadh>. clear wl_tabla. "Asignar valores a los cuatro campos que deben aparecer en el informe contador = sy-tabix. wl_tabla-idmuestra = pi_muestra. wl_tabla-nombre = 'MEDADHESION'. wl_tabla-cont = sy-tabix. concatenate 'Muestra' contador into wl_tabla-campo1 separated by ' '. wl_tabla-campo2 = <fs_medadh>-superficie. wl_tabla-campo3 = <fs_medadh>-adhesion. wl_tabla-campo4 = <fs_medadh>-tiporotura. call function 'Z_LB_CAMBIAR_FORMAT_DEC' exporting pi_formato_sap = wl_tabla-campo2 importing pe_formato_excel = wl_tabla-campo2. call function 'Z_LB_CAMBIAR_FORMAT_DEC' exporting pi_formato_sap = wl_tabla-campo3 importing pe_formato_excel = wl_tabla-campo3. condense wl_tabla-campo1. condense wl_tabla-campo2. condense wl_tabla-campo3. condense wl_tabla-campo4. "Se añade la linea a la tabla final append wl_tabla to pe_tabla. ENDLOOP. ENDFUNCTION. Código 22 Función para crear tabla dinámica de mediciones de adhesión 4.6.3. Tabla de configuración Todo lo desarrollado en los dos apartados anteriores es necesario para crear la pantalla, pero para que todo funcione correctamente y que se haga la generación del informe usando la plantillas, se debe configurar una tabal de base de datos llamada ZTLB_PLANTILLAS, que guarda en cada registro información sobre el nombre de la plantilla, identificador asociado por SAP para identificar la plantilla de forma univoca, además de otros datos, y para enlazar con el grupo de funciones desarrollado, esta tabla contiene una columna que guarda los nombres de módulos de función a los que se debe llamar para obtener todos los parámetros que tienen los valores de los campos del Word. 112 5.2. Pruebas Los usuarios que son programadores de SAP en el departamento de informática tienen acceso a todos los niveles de SAP. La fase de pruebas se ha hecho en el entorno de integración, aunque se han hecho pruebas iniciales en entorno de desarrollo que no se documentan en esta memoria. Las pruebas que se han hecho se dividen en dos grupos, pruebas de caja blanca y de caja negra que se definen a continuación.  La prueba de la caja blanca: es una técnica de prueba, que examina la estructura del programa y su código fuente.  La prueba de caja negra: en este tipo de pruebas se evalúa el sistema desde el punto de vista de entrada y salida, de manera que se debe producir la salida correcta según el valor de entrada. En este caso no se fija en el funcionamiento interno del sistema y cómo función pero se centra en lo qué hace. 5.2.1. Pruebas de caja blanca Estas pruebas han sido ejecutadas de forma paralela al avance de trabajo en el entorno de desarrollo, ya que todos los componentes que se desarrollaban tenían dependencias de otros, y para poder seguir adelante, siempre se tenía que verificar el funcionamiento del código y de los caminos de ejecución posibles de los diferentes programas antes de hacer cualquier avance. El análisis de caja negra se realiza con una herramienta de depuración integrada en el ABAP Workbench, y de forma similar a otras herramientas de desarrollo como Eclipse, la función de depuración se activa poniendo un punto de parada en el código, de esta manera se puede ver el contenido de todas las variables involucradas en la ejecución del programa, incluso las variables del sistema. Además esta herramienta permite cambiar el contenido de una variable durante el tiempo de ejecución y probar el funcionamiento como respuesta a ese cambio. La ilustración 76 muestra la ejecución del depurador de ABAP y otras características que ayuda en el momento de depurar el código. 113 Ilustración 76 Depurador de ABAP WorkBench 5.2.2. Pruebas de caja negra Estas pruebas son las que han sido más relevantes en el proyecto, ya que todos los datos que recoge el sistema igual que los que produce deben cumplir con la normativa que los regule. Al identificar las entradas y salidas del sistema a verificar, podemos resumirlos en los siguientes elementos:  Pantalla de entrada de muestras con sus nuevos campos.  Pantallas de entrada de resultados para cada ensayo.  Generación de borradores de forma correcta.  Generación de informes de forma correcta.  Generación del correo con tabla de resumen en el cuerpo.  Generación de lista de resultado con todos los datos de la muestra y del ensayo. Para poder verificar el funcionamiento se ha hecho una prueba empezando con la creación de una nueva muestra de tipo de mortero de albañilería, ilustración 77, luego se rellenan las pantallas de resultados que se adjuntan como anexos en las que vemos las pantallas de cada ensayo con los resultados que deben aparecer en el informe. A partir de la pantalla de resultados se genera el informe. Finalmente las ilustraciones 78 y 79 que exponen los datos de la muestra usando la transacción de listado de morteros y el cuerpo del correo de correspondencias respectivamente. La ilustración del listado solo muestra una 114 parte de los campos, ya que es muy extensa horizontalmente la pantalla, pero se entrega en el CD del TFG un documento HTML, generado usando el ALV, con todo el listado. Los borradores junto al informe se adjuntan como anexos de esta memoria, que forman la parte final de este libro, en el informe se pueden apreciar todos los datos relacionados con la muestra y sus ensayos. Se anexa el borrador y los dos informes, uno para una muestra de mortero de albañilería y otro de revoco de esta manera se demuestra el funcionamiento correcto de todo el sistema. Ilustración 77 Creación de nueva muestra y asignación de servicios Ilustración 78 Listado ALV después de la selección de parámetros de búsqueda 115 Ilustración 79 Correo de correspondencias de prueba con la tabla de resumen 116 6. Implantación y despliegue en producción Como hemos mencionado anteriormente la forma de desarrollar nuevas funcionalidades en SAP se hace en tres niveles, y el nivel en que tienen acceso los trabajadores de laboratorio para usar las nuevas funcionalidades desarrolladas en este TFG es él de producción. Lamentablemente en el momento de redacción de este documento aún no se ha podido realizar el despliegue en producción por razones ajenas a este proyecto, ya que hasta el momento de terminación de esta memoria el jefe de departamento, que es el administrador principal de redes y sistemas de la empresa, estaba llevando tareas de migraciones masivas y mantenimiento de los servidores donde está alojado el nivel de producción de SAP, lo que imposibilitó la realización de cualquier cambio en las bases de datos o el código. La integración en el nivel de producción se hará cuando acaben esas tareas de mantenimiento durante el periodo de una nueva beca ICARO conseguida para seguir formando parte del equipo de desarrollo. 117 7. Conclusiones La realización de este TFG ha supuesto un gran reto para poner en práctica todos los conceptos teóricos del desarrollo software aprendidos durante los años de la carrera y una gran oportunidad de inmersión dentro del mundo laboral en un entorno dinámico y con mucha presión para tener las infraestructuras de tecnologías de información funcionando bien para optimizar las operaciones de producción. 7.1. Objetivos cumplidos Como se ha señalado en el primer capítulo en el apartado de objetivos, este TFG tiene como objetivo global aumentar la usabilidad del ERP implantado por la empresa para evolucionar su forma de trabajo y mejorar el rendimiento en sus procesos además de añadir más control sobre la información para poder monitorizar y contabilizar los activos de la empresa. Con respecto a los objetivos específicos de este TFG, se puede considerar que se han cumplido con una satisfacción muy alta, ya que desde el punto de vista del departamento de laboratorio, que le dará uso a los nuevos componentes desarrolladas, este TFG aumentara la eficacidad de su forma de trabajar en cualquier operación que involucra el material de morteros, y desde el punto de vista técnico y del departamento de informática, el desarrollo se ha llevado cumpliendo con las reglas de desarrollo que ayudan al mantenimiento correctivo y evolutivo de cualquier funcionalidad agregada al ERP. A nivel personal se han adquirido varios conocimientos, sobre todo a nivel de gestión de proyectos, en los que la cooperación con otros miembros del equipo de desarrollo es necesaria para no caer en problemas de dependencias que causan latencias en el desarrollo, ya que el trabajo se ha hecho sobre el mismo sistema que siempre está en mantenimiento por otros desarrolladores. También destaca el aprendizaje en profundidad la tecnología ABAP, aunque falta mucha experiencia para poder decir que se ha llegado a un nivel de experto, pero según el jefe de desarrollo que es un consultor en SAP, el nivel asignado al alumno es desarrollador analista, por la soltura cogida a nivel de análisis, diseño y implementación usando esta tecnología durante todo el periodo del TFG. 7.2. Dificultades encontradas Dado que este TFG enlaza dos disciplinas de la ingeniería, sistemas de información y ciencia de materiales, uno de los grandes problemas era el poder entender el lenguaje que se usa de forma natural por los responsables del laboratorio que son la fuente de aclaración de las dudas relacionadas con las normas, ya que han surgido muchas dudas durante todo el desarrollo que se 118 relacionaban con datos indispensable para el TFG pero eran expresados en lenguaje puramente técnico. Todo eso ha creado una dependencia por el departamento de laboratorio, que a su vez tenía mucho trabajo y salidas del personal por trabajos fuera de la empresa CEMOSA, lo que dificultaba el acceso a información pertinente para completar la elaboración de la memoria, lo que ha complicado la finalización de este documento. La infraestructura de sistemas que tiene CEMOSA ha tenido un impacto también sobre el desarrollo del TFG, ya que tanto las caídas del sistema, como la inaccesibilidad por mantenimiento han impedido el acceso a los servidores donde están instalados todas las herramientas de desarrollo y el propio ERP. Otro problema destacable que ha afectado al desarrollo, es el desconocimiento de las operaciones de la empresa con mucho detalle en el inicio del desarrollo, lo que ha dificultado el arranque del TFG por falta de visión sobre los enlaces entre todos los módulos de SAP y su forma de uso por la parte de CEMOSA. 7.3. Mejoras posibles Una de las mejoras más inmediatas que se pueden hacer para el sistema de control de morteros, o de cualquier otro material, consistiría en hacer uso de las tecnologías web (HTML5, CSS3, Ajax…), en vez de pantallas DynPros internas a SAP y que son limitados para su acceso, de manera que las pantallas usadas para la entrada de muestras o la entrada de resultados sea directamente en una pagina web como frontend, y usando SAP como backend, de esta manera se podría invertir en material con que se acceda a la web (tabletas, iPad, …) donde se encuentren las pantallas para introducir los datos directamente y sin pasar por impresión de borradores o copiar albaranes que contienen información de muestras en otras hojas para luego introducir los datos al sistema. Esto supone un gran aumento de rapidez de trabajo y ahorro en costes de papal e impresión, ya que el operador de muestras o el operador de ensayos ellos mismos pueden introducir los datos al sistema, y la tarea del técnico de laboratorio estará más enfocada a la mejora de calidad del trabajo y servicios ofrecidos por CEMOSA. 119 8. Bibliografía y referencias [1] Dolinskaja, O. (s.f.). https://goo.gl/gHyWsz. Obtenido de SAP NetWeaver 7.5 – One common foundation for SAP Business Suite and SAP S/4HANA, on-premise edition. [2] Gaspard-Monge, I. d. (s.f.). https://goo.gl/tOj66w. Obtenido de Présentation des solutions SAP. [3]tutorialspoint. (s.f.). https://goo.gl/oQCXYj. Obtenido de SAP ABAP - Dictionary. [4] Seidor. Manuales de programación e introducción a SAP. [5] Karl-Heinz Kühnhauser (2008); Discover ABAP; Galileo Press [6] Horst Keller, Sascha Krüger (2007); ABAP Objects: ABAP Programming in SAP [7] NetWeaver; Galileo Press [8] SAP Virtual/Onsite Trainings; Adobe Interactive Forms Tutorials [9] Aenor, normas UNE-EN 1015-12 120 9. Ilustraciones, códigos y tablas Ilustraciones Ilustración 1 Organigrama del departamento de informática en CEMOSA __________________ 10 Ilustración 2 – Sistema de información de CEMOSA anterior a SAP _______________________ 12 Ilustración 3 Transversal de morteros en el modulo de laboratorio ________________________ 13 Ilustración 4 proceso de negocio de control de morteros anterior al TFG ___________________ 18 Ilustración 5 Control de mortero usando HCLabWin _____________________________________ 20 Ilustración 6 Control de mortero integrado en SAP-LAB con ABAP ________________________ 20 Ilustración 7 proceso de negocio de control de morteros posterior al TFG __________________ 22 Ilustración 8 Relaciones entre diferentes sistemas que componen una instalación completa de SAP _______________________________________________________________________________ 24 Ilustración 9 ABAP WorkBench _______________________________________________________ 25 Ilustración 10 cola de SAP NetWeaver _________________________________________________ 25 Ilustración 11 Principales módulos de SAP _____________________________________________ 27 Ilustración 12 El editor de código fuente de ABAP Workbench ____________________________ 28 Ilustración 13 Screen Painter, potente herramienta usada para diseñar todas las pantallas __ 29 Ilustración 14 Algunas transacciones en la tabla TSTC vistas desde el diccionario de datos, la SE11 usada para acceder al diccionario de datos _______________________________________ 30 Ilustración 15 Cambios automáticos en la BD al activar los objetos el diccionario ___________ 31 Ilustración 16 Tabla de cliente con estructura definida por el usuario ______________________ 32 Ilustración 17 Tipos de datos básicos de ABAP [4] ______________________________________ 33 Ilustración 18 foro de dudas dentro del intranet de CEMOSA _____________________________ 37 Ilustración 19 Diagrama de casos de uso ______________________________________________ 42 Ilustración 20 UC1 - Diagrama de secuencia de entrada de muestras _____________________ 43 Ilustración 21 UC-2 Diagrama de secuencia de asignación de servicios ___________________ 44 Ilustración 22 UC3 - Diagrama de secuencia de asignación de plantilla ____________________ 45 Ilustración 23 UC4 - Diagrama de secuencia de generación de borradores _________________ 46 Ilustración 24 UC5 - Diagrama de secuencia de entrada de resultados ____________________ 47 Ilustración 25 UC6 - Diagrama de secuencia de generación del informe __________________________ 48 Ilustración 26 UC7 - Diagrama de secuencia de correo de correspondencias _______________ 49 Ilustración 27 UC8 - Diagrama de secuencia de generación de listado _____________________ 49 Ilustración 28 Diagrama de flujo de entrada de muestras _________________________________ 51 Ilustración 29 Entrada de muestras general modificada __________________________________ 52 Ilustración 30 Porción del modelo de dominio del laboratorio _____________________________ 54 Ilustración 31 Tabla de muestras y la tabla que relaciona muestras con los servicios ________ 54 Ilustración 32 Ensayo de absorción de agua ____________________________________________ 56 Ilustración 33 modelo de datos del ensayo de absorción _________________________________ 56 Ilustración 34 Pantalla del ensayo de absorción de agua _________________________________ 57 Ilustración 35 Ensayo de densidad aparente ____________________________________________ 57 Ilustración 36 Modelo de datos del ensayo de densidad aparente _________________________ 58 Ilustración 37 Pantalla del ensayo de densidad aparente _________________________________ 58 Ilustración 38 Tipos de rotura en ensayo de adhesión de morteros ________________________ 59 Ilustración 39 Excel del ensayo de adhesión ____________________________________________ 60 Ilustración 40 Modelo de datos del ensayo de adhesión _________________________________ 60 Ilustración 41 Pantalla del ensayo de adhesión _________________________________________ 61 Ilustración 42 Excel del ensayo de contenido en cloruros ________________________________ 61 Ilustración 43 Modelo de datos del ensayo de contenido en cloruros ______________________ 62 Ilustración 44 Pantalla de ensayo de contenido en cloruros ______________________________ 62 Ilustración 45 Ensayos de consistencia y aire ocluido ____________________________________ 63 Ilustración 46 Modelo de datos del ensayo de consistencia y aire ocluido __________________ 63 Ilustración 47 Excel de ensayo de flexión y compresión __________________________________ 64 Ilustración 48 Modelo de datos del ensayo de resistencia a la flexión y compresión _________ 64 Ilustración 49 pantalla de ensayo de resistencia a flexión y compresión ____________________ 65 Ilustración 50 Funcionalidades del ALV ________________________________________________ 67 121 Ilustración 51 Estructura de un ModulPool _____________________________________________ 69 Ilustración 52 Modules de procesos y su funcionamiento _________________________________ 70 Ilustración 53 Tabla de ZTLB_USOARIDOS ____________________________________________ 71 Ilustración 54 Modelo de dominio que representa la relación MATERIAL-USO _____________ 71 Ilustración 55 Tabla que relaciona materiales con los usos, ZTLB_USOMATERIAL _________ 72 Ilustración 56 Creación de ayuda de búsqueda en el diccionario y asociarla con la función de salida ______________________________________________________________________________ 72 Ilustración 57 Ayuda de búsqueda para uso previsto en entrada de morteros _______________ 75 Ilustración 58 Ayuda de búsqueda de uso de morteros __________________________________ 76 Ilustración 59 Tabla de mediciones del ensayo de absorción ZTLB_MOMEDABS ___________ 77 Ilustración 60 Tabla general del ensayo de absorción ____________________________________ 77 Ilustración 61 Elemento de datos y dominio de campo de capilaridad media ________________ 78 Ilustración 62 Estructura para trabajar en ABAP con la tabla de mediciones del ensayo de absorción __________________________________________________________________________ 79 Ilustración 63 Estructura profunda con datos generales y una lista de mediciones __________ 80 Ilustración 64 Grupo de funciones de ensayos de mortero _______________________________ 85 Ilustración 65 Intefase del borrador de morteros ________________________________________ 94 Ilustración 66 Estructura profunda con todos las estructuras de los ensayos _______________ 94 Ilustración 67 LiveCycle para el diseño de los borradores con ADOBE_____________________ 95 Ilustración 68 Configuración de borradores en la tabla de materiales ______________________ 96 Ilustración 69 Creación propiedades de Word, se ha marcado el campo de valor de resistencia a flexión a 14 días para dar un ejemplo _______________________________________________ 101 Ilustración 70 Asociar fórmulas con propiedades de Word _______________________________ 102 Ilustración 71 Estructura con todos los datos del informe ________________________________ 102 Ilustración 72 Configuración de tabla de plantillas ______________________________________ 106 Ilustración 73 Tabla de configuración del correo con registros de mortero _________________ 106 Ilustración 74 Organizador de ordenes de transporte para liberarlas ______________________ 111 Ilustración 75 Sistema de transporte de desarrollo a integración _________________________ 111 Ilustración 76 Depurador de ABAP WorkBench ________________________________________ 113 Ilustración 77 Creación de nueva muestra y asignación de servicios _____________________ 114 Ilustración 78 Listado ALV después de la selección de parámetros de búsqueda __________ 114 Ilustración 79 Correo de correspondencias de prueba con la tabla de resumen ____________ 115 Código fuente Código 1 Select de uso previsto ............................................................................................................ 74 Código 2 Module de entrada de muestras ........................................................................................... 81 Código 3 Module de modificación de campos mortero ...................................................................... 81 Código 4 Obtener descripción de uso del material ............................................................................. 82 Código 5 Obtener el nombre de la planta ............................................................................................ 83 Código 6 Obtener el texto de tipo de cemento .................................................................................... 84 Código 7 Proceso de carga de datos del ensayo de absorción ....................................................... 86 Código 8 Gestión de comandos de usuario en el PAI del ensayo de absorción ........................... 87 Código 9 Módulo de función que guarda los datos de todo el ensayo de absorción .................... 88 Código 10 función que guarda las mediciones de absorción en la base de datos ........................ 89 Código 11 Llamada de la función para calcular la absorción de agua y mostrar mensaje según valor de variable de errores ................................................................................................................... 89 Código 12 Código de cálculo de la absorción de agua ...................................................................... 90 Código 13 inicialización de ensayo de absorción para el borrador .................................................. 92 Código 14 Llamadas a cada módulo de función para inicializar los ensayos ................................ 93 Código 15 Programa REPORT de ALV ............................................................................................... 97 Código 16 Función de selección, dentro se hace la llamada al la función que devuelve el listado de morteros ............................................................................................................................................... 97 Código 17 Módulo de función principal de obtención de todos los resultados de mortero .......... 98 Código 18 Select a la tabla de muestras que devuelve todas las que cumplen con los parámetos ................................................................................................................................................. 99 Código 19 Módulo de función que hace un select a la tabla general de absorción ...................... 99 128 129 130 131 Anexo C. Ejemplo de Informe de mortero de revoco 132 133 134 135 136 137