SOLUCIÓN DE MOVILIDAD SOBRE SAPUI5 PARA EL MÓDULO DE SAP HCM

Transcripción

1 GRADO INGENIERÍA TELEMÁTICA SOLUCIÓN DE MOVILIDAD SOBRE SAPUI5 PARA EL MÓDULO DE SAP HCM Autor: María Gil Cárdenas Director: Roberto Pajares Gutiérrez MADRID Junio, 2014

2

3 AUTORIZACIÓN PARA LA DIGITALIZACIÓN, DEPÓSITO Y DIVULGACIÓN EN ACCESO ABIERTO DE DOCUMENTACIÓN 1º. Declaración de la autoría y acreditación de la misma. El autor Dña. María Gil Cárdenas, como alumna de la UNIVERSIDAD PONTIFICIA COMILLAS (COMILLAS), DECLARA que es el titular de los derechos de propiedad intelectual, objeto de la presente cesión, en relación con la obra trabajo fin de grado: solución de movilidad sobre SAPUI5 para el módulo de SAP HCM, que ésta es una obra original, y que ostenta la condición de autor en el sentido que otorga la Ley de Propiedad Intelectual como titular único o cotitular de la obra. En caso de ser cotitular, el autor (firmante) declara asimismo que cuenta con el consentimiento de los restantes titulares para hacer la presente cesión. En caso de previa cesión a terceros de derechos de explotación de la obra, el autor declara que tiene la oportuna autorización de dichos titulares de derechos a los fines de esta cesión o bien que retiene la facultad de ceder estos derechos en la forma prevista en la presente cesión y así lo acredita. 2º. Objeto y fines de la cesión. Con el fin de dar la máxima difusión a la obra citada a través del Repositorio institucional de la Universidad y hacer posible su utilización de forma libre y gratuita ( con las limitaciones que más adelante se detallan) por todos los usuarios del repositorio y del portal e-ciencia, el autor CEDE a la Universidad Pontificia Comillas de forma gratuita y no exclusiva, por el máximo plazo legal y con ámbito universal, los derechos de digitalización, de archivo, de reproducción, de distribución, de comunicación pública, incluido el derecho de puesta a disposición electrónica, tal y como se describen en la Ley de Propiedad Intelectual. El derecho de transformación se cede a los únicos efectos de lo dispuesto en la letra (a) del apartado siguiente. 3º. Condiciones de la cesión. Sin perjuicio de la titularidad de la obra, que sigue correspondiendo a su autor, la cesión de derechos contemplada en esta licencia, el repositorio institucional podrá: (a) Transformarla para adaptarla a cualquier tecnología susceptible de incorporarla a internet; realizar adaptaciones para hacer posible la utilización de la obra en formatos electrónicos, así como incorporar metadatos para realizar el registro de la obra e incorporar marcas de agua o cualquier otro sistema de seguridad o de protección. (b) Reproducirla en un soporte digital para su incorporación a una base de datos electrónica, incluyendo el derecho de reproducir y almacenar la obra en servidores, a los efectos de garantizar su seguridad, conservación y preservar el formato..

4 (c) Comunicarla y ponerla a disposición del público a través de un archivo abierto institucional, accesible de modo libre y gratuito a través de internet. (d) Distribuir copias electrónicas de la obra a los usuarios en un soporte digital. 4º. Derechos del autor. El autor, en tanto que titular de una obra que cede con carácter no exclusivo a la Universidad por medio de su registro en el Repositorio Institucional tiene derecho a: a) A que la Universidad identifique claramente su nombre como el autor o propietario de los derechos del documento. b) Comunicar y dar publicidad a la obra en la versión que ceda y en otras posteriores a través de cualquier medio. c) Solicitar la retirada de la obra del repositorio por causa justificada. A tal fin deberá ponerse en contacto con el vicerrector/a de investigación (curiarte@rec.upcomillas.es). d) Autorizar expresamente a COMILLAS para, en su caso, realizar los trámites necesarios para la obtención del ISBN. d) Recibir notificación fehaciente de cualquier reclamación que puedan formular terceras personas en relación con la obra y, en particular, de reclamaciones relativas a los derechos de propiedad intelectual sobre ella. 5º. Deberes del autor. El autor se compromete a: a) Garantizar que el compromiso que adquiere mediante el presente escrito no infringe ningún derecho de terceros, ya sean de propiedad industrial, intelectual o cualquier otro. b) Garantizar que el contenido de las obras no atenta contra los derechos al honor, a la intimidad y a la imagen de terceros. c) Asumir toda reclamación o responsabilidad, incluyendo las indemnizaciones por daños, que pudieran ejercitarse contra la Universidad por terceros que vieran infringidos sus derechos e intereses a causa de la cesión. d) Asumir la responsabilidad en el caso de que las instituciones fueran condenadas por infracción de derechos derivada de las obras objeto de la cesión.

5 6º. Fines y funcionamiento del Repositorio Institucional. La obra se pondrá a disposición de los usuarios para que hagan de ella un uso justo y respetuoso con los derechos del autor, según lo permitido por la legislación aplicable, y con fines de estudio, investigación, o cualquier otro fin lícito. Con dicha finalidad, la Universidad asume los siguientes deberes y se reserva las siguientes facultades: a) Deberes del repositorio Institucional: - La Universidad informará a los usuarios del archivo sobre los usos permitidos, y no garantiza ni asume responsabilidad alguna por otras formas en que los usuarios hagan un uso posterior de las obras no conforme con la legislación vigente. El uso posterior, más allá de la copia privada, requerirá que se cite la fuente y se reconozca la autoría, que no se obtenga beneficio comercial, y que no se realicen obras derivadas. - La Universidad no revisará el contenido de las obras, que en todo caso permanecerá bajo la responsabilidad exclusiva del autor y no estará obligada a ejercitar acciones legales en nombre del autor en el supuesto de infracciones a derechos de propiedad intelectual derivados del depósito y archivo de las obras. El autor renuncia a cualquier reclamación frente a la Universidad por las formas no ajustadas a la legislación vigente en que los usuarios hagan uso de las obras. - La Universidad adoptará las medidas necesarias para la preservación de la obra en un futuro. b) Derechos que se reserva el Repositorio institucional respecto de las obras en él registradas: - retirar la obra, previa notificación al autor, en supuestos suficientemente justificados, o en caso de reclamaciones de terceros. Madrid, a 5 de Junio de 2014 ACEPTA Fdo: María Gil Cárdenas

6 Autorizada la entrega del proyecto del alumno/a: María Gil Cárdenas EL DIRECTOR DEL PROYECTO Roberto Pajares Gutiérrez Fdo.: Fecha: / / Vº Bº del Coordinador de Proyectos David Contreras Bárcena Fdo.: Fecha: / /

7 GRADO INGENIERÍA TELEMÁTICA SOLUCIÓN DE MOVILIDAD SOBRE SAPUI5 PARA EL MÓDULO DE SAP HCM Autor: María Gil Cárdenas Director: Roberto Pajares Gutiérrez MADRID Junio, 2014

8 Agradecimientos Me gustaría agradecer en primer lugar a mis padres, por su apoyo incondicional, por tantas oportunidades que he tenido siempre y por aguantar mi mal humor y peores momentos durante estos cuatro años. También a todos los profesores y compañeros de ICAI, con los que he tenido la suerte de compartir tantas experiencias bonitas y algunas un poco más duras. Por último, a todo el equipo de movilidad de everis, a Roberto Pajares y a Nacho Pareja, gracias por hacerlo todo más fácil y por el cariño en todo momento.

9 SOLUCIÓN DE MOVILIDAD SOBRE SAPUI5 PARA EL MÓDULO DE SAP HCM Autor: Gil Cárdenas, María Director: Pajares Gutiérrez, Roberto Entidad Colaboradora: everis Spain S.L. RESUMEN DEL PROYECTO En la sociedad empresarial actual queda patente la necesidad de aplicaciones móviles de fácil uso para mejorar los procesos de negocio. A día de hoy, no hay duda de que en los próximos años las aplicaciones Fiori serán la forma unánime de interacción con los sistemas SAP. Es por eso que en este proyecto hemos implementado nueva funcionalidad en una solución móvil de interfaz Fiori. Los nuevos procesos SAP implementados están en relación con el módulo de recursos humanos o HCM (en inglés Human Capital Management). A través de esta nueva solución móvil se permite acceder e interaccionar con los datos del personal de RRHH de una organización. Palabras clave: Sap, Fiori, R/3, NetWeaver Gateway, SAPUI5, RFC 1. INTRODUCCIÓN Este proyecto se va a desarrollar en colaboración con la empresa multinacional de consultoría EVERIS, de origen español. Desde hace tiempo, everis mantiene una alianza con la empresa SAP AG, que le permite implantar, desarrollar e investigar con sistemas SAP ERP. La implantación de un sistema ERP (un sistema integrado de Planificación de Recursos Empresariales) en una organización, permite la integración global y sencilla de los procesos de negocio, creando un entorno de trabajo más eficiente y dotando a sus usuarios de información en tiempo real, reduciendo la posibilidad de errores e información redundante. I

10 En este proyecto se van a implantar algunos procesos del módulo HCM a una organización ficticia, para posteriormente movilizarlos y hacerlos accesibles desde una aplicación. El trabajo se ha llevado a cabo haciendo uso de uno de los laboratorios de desarrollo SAP en everis y con el apoyo del equipo de soluciones móviles y del equipo de SAP HCM de dicha empresa. 2. TECNOLOGÍAS Las tecnologías que se han utilizado para la consecución de este proyecto son: SAP R/3: es un entorno ERP donde se desarrolla la estructura organizativa de una empresa llamada SES (nombre tomado del sector Sap&Enterprise Solutions de everis). EL R/3 es la plataforma de parametrización, para crear, almacenar y gestionar los datos. SAP NetWeaver Gateway: es una plataforma de tecnología integrada que actúa de pasarela entre la información que hay en el SAP R/3 y el framework de desarrollo SAPUI5. Es un sistema intermedio necesario para que el interfaz de usuario pueda acceder a los datos en el back-end del sistema. Como se muestra en la Ilustración 1, la conexión entre el Gateway y el SAPUI5 se realiza vía HTTP, a través del protocolo OData; mientras que en la conexión entre el R/3 y el Gateway hace uso de funciones RFC (Remote Function Call), programadas en lenguaje ABAP/4 y encargadas de recoger los datos del sistema para servírselos al servicio de gateway. SAPUI5: es el entorno de desarrollo de aplicaciones SAP en HTML5. Se trata de un User Interface Add-on para el Sap NetWeaver. Se hará uso del SAP Development Kit UI para HTML5, instalado como un plugin del IDE Eclipse Juno. Es una tecnología de interfaz de usuario que se utiliza para construir y adaptar las aplicaciones cliente basadas en SAP NetWeaver. En la siguiente figura vemos un esquema de la arquitectura completa de la solución y de cómo se produce la transmisión de datos entre bloques. II

11 Ilustración 1: Diagrama del flujo de datos en el sistema 3. OBJETIVOS En la siguiente tabla se muestran los objetivos principales de este proyecto. Cada uno de ellos a su vez se dividirá en fases y tareas a realizar para la consecución del objetivo completo. ID OBJ-1 OBJ-2 OBJ-3 OBJ-4 OBJ-5 OBJ-6 OBJ-7 OBJETIVO Estudio del sistema SAP R/3 y del módulo de SAP HCM Diseño de una estructura organizativa modelo. Parametrización en el sistema de los módulos necesarios Análisis y diseño de la solución móvil Programación de las RFCs con ABAP Configuración del Sap NetWeaver Gateway Programación de la solución móvil con SAPUI5 Tabla 1: Objetivos III

12 4. DESCRIPCIÓN DEL TRABAJO REALIZADO Este proyecto consiste en parametrizar la información de los empleados de una organización dentro del área SAP, en el sistema SAP HCM (en inglés Human Capital Management) y posteriormente en movilizar algunos de los procesos de este módulo (los considerados interesantes desde el punto de vista de recursos humanos para una aplicación móvil) mediante soluciones SAP innovadoras, como son SAP Fiori y SAPUI5. Se ha realizado en primer lugar un estudio del sistema SAP R/3 y del módulo de SAP HCM, realizando diversas pruebas y demos dentro del laboratorio de desarrollo de everis. Después se ha hecho una parametrización en el sistema del módulo HCM a una compañía ficticia. Para ello, se ha elaborado un plan de organización en el sistema SAP R/3. Un plan de organización proporciona un modelo completo del entorno personal y de la estructura organizativa con jerarquías y organigramas. Posteriormente, se ha hecho un estudio acerca de los procesos del SAP R/3 que se pueden movilizar a la aplicación. Estos procesos, que se corresponden con el alcance de la solución móvil final son: - Visualización de datos de empleados - Buscar empleados - Modificar datos personales - Consultar cualificaciones - Buscar empleados que posean una cualificación - Consultar cursos formativos Después se ha efectuado un estudio y configuración acerca de la herramienta SAP NetWeaver Gateway, que sirve de pasarela para transferir los datos desde el sistema R/3 al front-end de la aplicación. Este proceso se realiza a través de RFCs, que ha sido necesario desarrollar en lenguaje ABAP/4. Finalmente, se ha programado en la plataforma SAPUI5 la aplicación móvil que pueda acceder a los datos del sistema y ejecutar acciones sobre ellos. IV

13 5. RESULTADOS La solución móvil que hemos diseñado tiene la siguiente apariencia. Al arrancar la aplicación se muestran los tres iconos de acceso rápido a la funcionalidad: Datos de empleados, Cualificaciones y Cursos Formativos: Al hacer click en el primero de los iconos se navega hasta la vista de visualización de datos de empleados. En la figura de la izquierda se observa la vista principal. Dentro de esta figura, a la izquierda aparece una lista con todos los empleados de la compañía SES con una muy breve descripción, nombre, apellidos y número de empleado; y a la derecha aparece el detalle de cada empleado: resumen en la parte superior y tres sub-iconos que agrupan el resto de datos: cada uno de ellos corresponde a datos personales, asignación organizativa y cualificaciones personales. En la figura de la derecha vemos el formulario de actualización de datos personales de un empleado. Este formulario aparece cuando se selecciona el botón Editar datos. Una vez relleno se enviaría al sistema pulsando el botón Update. V

14 En la figura de la izquierda se observa la navegación del segundo de los iconos de acceso rápido. Se trata del resumen de cualificaciones y empleados que las satisfacen. En la parte superior se encuentra la barra de búsqueda. La figura de la derecha muestra la navegación hacia la vista de cursos formativos. En la columna izquierda se muestran los nombres de los cursos disponibles y a la derecha un resumen de las habilidades que se adquieren al realizar dicho curso. 6. CONCLUSIONES Con este proyecto, se ha conseguido una nueva aplicación Fiori con una funcionalidad que no existía hasta el momento. La aplicación es simple, porque todas las aplicaciones Fiori lo deben ser. El valor de las aplicaciones Fiori radica en su sencillez en cuanto a funcionalidad y presentación. El producto Fiori fue lanzado hace poco menos de un año, y en este tiempo ha tenido una enorme evolución. Se estima que en los próximos tres años será la forma unánime de acceso a los sistemas SAP de back-end. Si agrupamos la funcionalidad de nuestro desarrollo móvil final, encontramos que está compuesto por tres nuevas aplicaciones Fiori: Visualización y actualización de datos personales. Vista de cualificaciones y búsqueda de empleados por cualificación. Consulta de cursos formativos disponibles. VI

15 7. REFERENCIAS Las principales referencias y fuentes de consulta utilizadas durante la realización de este proyecto son: [SAPAG] Documentación oficial de SAP AG. Obtenida a través del partnership establecido con la empresa everis, entidad colaboradora de este proyecto. [WWW01] SAP A.G. Comunidad SAP. Última visita: 18 de mayo de [WWW02] SAP A.G. Sap Help Portal Última visita: 18 de mayo de VII

16 VIII

17 MOVILITY SOLUTION OVER SAPUI5 FOCUSING ON THE SAP HCM MODULE Author: Gil Cárdenas, María Supervisor: Pajares Gutiérrez, Roberto Collaborating Entity: everis ABSTRACT In today's business society the need for mobile applications used in an easy way is demonstrated to improve business processes. Today, there is no doubt that in the coming years the Fiori applications will unanimously be the way of interaction with SAP systems. That's why in this project we have implemented new functionality in a mobile solution with Fiori interface. The new SAP processes which are implemented are focused on the HCM SAP s module (Human Capital Management). Through this new mobile solution access and interaction with HR staff data is allowed. Keywords: Sap, Fiori, R/3, NetWeaver Gateway, SAPUI5, RFC 1. INTRODUCTION This project will be developed in collaboration with the multinational consulting company EVERIS, of Spanish origin. For some time EVERIS has a partnership with SAP AG, which allows to implement, develop and research with SAP ERP systems. The implementation of an ERP system in an organization (an integrated Enterprise Resource Planning system) allows an easy integration of global business processes, creating a more efficient work environment and providing information to users in realtime, while reducing the possibility of errors and redundant information. IX

18 In this project we are going to implement some processes of the HCM module to a simulated organization, then they will be mobilized and made accessible from an application. The work has been carried out using one of the SAP development laboratories and with the support of the everis mobile solutions team and the SAP HCM team. 2. TECHNOLOGIES The technologies that have been used to achieve this project are: SAP R/3: is an ERP environment where the organizational structure of the simulated company called 'SES' (name taken from the everis sector called Sap & Enterprise Solutions ) is developed. The R/3 is the platform for customizing, creating, storing and managing data. SAP NetWeaver Gateway: is an integrated technology platform that acts as a bridge between the information that is in the SAP R/3 and the SAPUI5 framework. It is necessary for the user interface to access the data in the back-end system. As shown in Figure 1, the connection between the Gateway and SAPUI5 is via HTTP, thought the OData protocol; while the connection between R/3 and the Gateway uses functions called RFCs (Remote Function Calls) which are programmed in ABAP/4 and are in charge of collecting data from the system to serve them to the service gateway. SAPUI5: is the development environment of SAP applications in HTML5. This is a User Interface Add-on for SAP NetWeaver. In this project will use the SAP Development Kit for HTML5 UI, installed as a plugin to Juno Eclipse IDE. It is a UI technology that is used to build and adapt client applications based on SAP NetWeaver. The following figure shows a diagram of the overall architecture of the solution and how the data transmission between blocks is produced. X

19 Ilustración 2: Data flow diagram 3. GOALS The following table lists the main objectives in this project. In turn, each one is divided into phases and tasks to achieve the overall objective. ID OBJ-1 OBJ-2 OBJ-3 OBJ-4 OBJ-5 OBJ-6 OBJ-7 OBJECTIVE Studing SAP R / 3 system and its SAP HCM module Designing an organizational structure as a model. Customizing the system required modules Analysing and designing the mobile solution Programming the RFCs with ABAP Configuring Sap NetWeaver Gateway Programming the mobile solution over SAPUI5 XI

20 4. DESCRIPTION OF WORK This project consists in customizing the company s employees data within the SAP area, in the SAP HCM module, and then to mobilize some of the processes of this module (the ones considered interesting from the HR point of view for a mobile application) through innovative SAP solutions such as SAP Fiori and SAPUI5. Firstly, a study of the SAP R/3 and SAP HCM module was made, performing various tests and demos in the development lab in everis. Then it was made the customizing of the HCM module to a fictitious company. To do this, an organizational plan in the SAP R/3 system must be developed. An organizational plan provides a complete model of the personal environment and the organizational structure and organizational hierarchies. Subsequently, we made a study of the processes of the SAP R/3 that can be mobilized to the application. These processes correspond to the final reach of the complete solution: - Display employee data - Search for employees - Update personal data - Check qualifications - Find employees who possess a qualification - Check training courses After that, a study about the SAP NetWeaver Gateway tool has been made. This tool performs as a gateway to transfer the data from the R/3 system to the front-end application. This process is performed through RFCs, which had to be developed in ABAP/4 language. Finally, we have programmed the mobile application over the SAPUI5 platform. This application can access system data and perform actions on them. XII

21 5. RESULTS The mobile solution we designed looks like this. When starting the application the three icons for quick access to functionality are shown: Employee Data, Qualifications and Training Courses: When clicking on the first icon, it navigates to view display employee data. In the left figure the main view is observed. Within this figure: in the left it shows a list with all SES employees with a very brief description, name and employee number; and in the right: it is the detail of each employee: short on top, and three subicons that group the remaining data: each one of them corresponds to personal data, organizational assignment and personal qualifications. The figure at the right shows the form for updating the employee personal data. This form appears when the 'Editar datos' button is selected. When the form is filled, it will be sent to the system by pressing the Update button. XIII

22 In the figure at the left it is shown the navigation of the second shortcut icon. This is a summary of qualifications and all the employees that satisfy them. At the top is the search bar. The right figure shows the navigation to the training courses view. In the left column are the names of the courses available and in the right one it is a summary of the skills that are acquired by taking this course. 6. CONCLUSIONS This project has achieved a new Fiori application with functionality that did not exist so far. The application is simple, because all applications Fiori should be. The value of Fiori applications is about its simplicity in terms of functionality and presentation. The Fiori product was launched for a little less than a year, and in that time has had an enormous evolution. It is estimated that over the next three years will be the unanimous way of accessing to SAP backend systems. If we group the functionality of our mobile development, at the end, we found that it consists of three new Fiori applications: View and update personal information. View and search skills of employees by qualification. Consultation of training courses available. XIV

23 7. REFERENCES The main references and sources used during this project are: [SAPAG] Oficial SAP AG documentation. Obtained through the partnership with the everis company, colaborating entity of this project. [WWW01] SAP A.G. SAP Community. Last visit: 18 May, [WWW02] SAP A.G. Sap Help Portal Last visit: 18 May, XV

24 XVI

25 MEMORIA Índice de figuras Ilustración 1: Diagrama del flujo de datos en el sistema... III Ilustración 2: Data flow diagram... XI Ilustración 3: HR Renewal Ilustración 4: Sap Fiori, principios de diseño... 7 Ilustración 5: Algunas aplicaciones Fiori... 8 Ilustración 6: Vista Apps Fiori en varios dispositivos... 8 Ilustración 7: Módulos del sistema R/ Ilustración 8: Herramienta guía IMG Ilustración 9: Herramienta transacción SM Ilustración 10 : Arquitectura del sistema R/ Ilustración 11: Estructura de la empresa Ilustración 12: Estructura organizativa, de empresa y de personal Ilustración 13: Secuencia de infotipos al aplicar una medida de personal Ilustración 14: Ejemplo de catálogo de cualificaciones Ilustración 15 : Ejemplo de servicio de gateway Ilustración 16: Modelo Vista Controlador Ilustración 17: Ejemplo de proyecto Fiori Ilustración 18 : Etiqueta bootstrap (index.html) Ilustración 19: Menú usuario Fiori Ilustración 20_ Master-Detail page. Fiori Ilustración 21: Controles SAP Fiori Ilustración 22: Diagrama de planificación Ilustración 23: Estimación económica Ilustración 24 : Estructura de la compañía modelo SES Ilustración 25: Selección de conexión, Sap Logon Ilustración 26: Pantalla de entrada al sistema SAP XVII

26 Ilustración 27 : Guía IMG Ilustración 28: Ejemplo parametrización: Subdivisiones de persona Ilustración 29: Ejemplo de parametrización: asociación división-sociedad GL Ilustración 30: Ejemplo de parametrización: Grupos y áreas de personal Ilustración 31: Menú SAP Easy Access Ilustración 32: Plan de organización SES Ilustración 33: Ejemplo parametrización: crear posiciones Ilustración 34: Ejemplo parametrización: medidas de personal Ilustración 35: Infotipos de personal SES Ilustración 36: Diagrama de casos de uso Ilustración 37: Arquitectura del sistema Ilustración 38: Diagrama secuencia 1: VISUALIZAR DATOS DE LOS EMPLEADOS Ilustración 39: Diagrama de secuencia 2: BUSCAR EMPLEADOS Ilustración 40: Diagrama de secuencia 3: MODIFICAR DATOS PERSONALES Ilustración 41: Diagrama de secuencia 4: CONSULTAR CUALIFICACIONES Ilustración 42: Diagrama de secuencia 5: BUSCAR EMPLEADOS QUE POSEAN UNA CUALIFICACIÓN Ilustración 43: Diagrama de secuencia 6: CONSULTAR CATÁLOGO DE CURSOS FORMATIVOS Ilustración 44: Grupo de funciones Z_RH_MGC Ilustración 45: Estructura ZHR_INFTY Ilustración 46: Exports Z_INFOEMPLEADOS Ilustración 47: Imports Z_INFOEMPLEADOS Ilustración 48: Diagrama de bloques Z_INFOEMPLEADOS Ilustración 49: Test Prueba Z_INFOEMPLEADOS Ilustración 50: Tabla ZTHR_INFTY Ilustración 51: Diagrama de bloques Z_EMPLEADOS Ilustración 52: Test Prueba Z_EMPLEADOS Ilustración 53: Diagrama de bloques Z_UPDATE_EE Ilustración 54: Estructura ZHR_CUAL Ilustración 55: Tabla ZTHR_CUAL Ilustración 56: Diagrama de bloques Z_CUALIFICACIONES XVIII

27 Ilustración 57: Estructura ZHR_CURSO Ilustración 58: Tabla ZTHR_CURSO Ilustración 59: Diagrama de bloques Z_CURSOS Ilustración 60: Modelo de datos Z_SAPHCM Ilustración 61: Entity Types: ZInfo y ZCual Ilustración 62: Entity Sets Ilustración 63: Generación de objetos Ilustración 64: Objetos generados Ilustración 65: Métodos autogenerados Ilustración 66: Métodos redefinidos Ilustración 67: Ejemplo de petición HTTP al modelo OData Ilustración 68: Proyecto de la solución móvil final Ilustración 69: Carpeta Web Content de la solución móvil final Ilustración 70: Submódulos de Administración de Personal PA Ilustración 71: Submódulos de Desarrollo de Personal PD XIX

28 Índice de tablas Tabla 1: Objetivos... III Tabla 2: Objetivos Tabla 3: Divisiones, subdivisiones, funciones y posiciones Tabla 4: Parametrización: Sociedad GL Tabla 5: Parametrización: División Tabla 6: Parametrización: Divisiones de personal Tabla 7: Parametrización: Subdivisiones de personal Tabla 9: Parametrización: grupos y áreas de personal Tabla 10: Caso de uso 1: Visualizar datos de empleados Tabla 11: Caso de uso 2: Buscar empleados Tabla 12: Caso de uso 3: Modificar datos personales Tabla 13: Caso de uso 4: Consultar cualificaciones Tabla 14: Caso de uso 5: Buscar empleados que posean una cualificación Tabla 15: Caso de uso 6: Consultar catálogo de cursos formativos XX

29 Índice del contenido 1. Introducción y justificación del proyecto Introducción general Estado de la cuestión. Antecedentes y alternativas Sap App Mobile para RRHH HR Renewal Aplicaciones Sap Fiori Motivación Estado de la técnica Sap R/ Arquitectura SAP R/ Módulo SAP HCM Estructuras en Recursos Humanos Administración de personal (PA) Desarrollo de personal (PD) RFC (Remote Function Call) Sap NetWeaver Gateway Servicio OData SAPUI SAP Fiori Definición del proyecto Objetivos Metodología Planificación y estimación económica XXI

30 5. Descripción de la solución Diseño de la estructura organizativa modelo Parametrización SAP Estructura empresarial Estructura personal Estructura organizativa Análisis y diseño de la solución móvil Casos de uso Estudio arquitectura del sistema Diagramas de secuencia Programación de las RFCs (Remote Function Call) Z_INFOEMPLEADOS Z_EMPLEADOS Z_UPDATE_EE Z_CUALIFICACIONES Z_CURSOS Servicio OData en el Sap NetWeaver Gateway Modelo de datos Redefinición de métodos Programación de la solución móvil en SAPUI Análisis de resultados Conclusiones y trabajos futuros Bibliografía XXII

31 1. Introducción y justificación del proyecto 1.1. Introducción general Las tecnologías de la información y la comunicación no son ninguna panacea ni fórmula mágica, pero pueden mejorar la vida de todos los habitantes del planeta. Así comenzaba Kofi Annan su discurso inaugural de la CMSI (Cumbre Mundial de la Sociedad de la Información) en el 2003, en Ginebra. Y es que las TIC (Tecnologías de la Información y las Comunicaciones) han revolucionado el mundo en el que vivimos desde hace ya varios años, tanto el personal como el profesional. Los rápidos avances y el crecimiento en el uso de Internet, han provocado un cambio en la manera tradicional del desarrollo de la actividad empresarial. En pleno siglo XXI, se puede afirmar que los smartphones juegan un papel fundamental en la vida de muchas personas. En los últimos años se ha producido un crecimiento exponencial de las ventas de estos teléfonos inteligentes. Este es uno de los motivos por el que las aplicaciones para dispositivos móviles se han revelado como un mercado emergente con grandes posibilidades. Como usuarios habituales de dispositivos inteligentes esto nos puede parecer una obviedad, pero si nos paramos a pensar en el mundo profesional, puede surgirnos la pregunta de para qué me pueden servir las aplicaciones del trabajo en mi teléfono móvil? En el marco empresarial las aplicaciones móviles permiten a las compañías aumentar su productividad notablemente, incrementando la satisfacción de empleados y gerentes. La utilización de las TIC y de los teléfonos inteligentes permite a los empresarios transformar los "datos" en "información", lo que ayuda notablemente a los directivos en la toma de decisiones. Las aplicaciones móviles han favorecido muchas de 1 P á g i n a

32 las actividades empresariales, como por ejemplo, agilizar los procesos internos, realizar transmisiones de datos financieros de manera segura, mejorar la comunicación interna y externa, y poder gestionar los sistemas de back-end. En este proyecto vamos a basarnos en el formato de SAP de desarrollo de aplicaciones y productos software. Pero qué es SAP? SAP AG 1 es una compañía alemana con sede en Waldorf que desde el año 1972 viene desarrollando aplicaciones y sistemas informáticos para la gestión de negocios y organizaciones. Es catalogada por Gartner 2 como líder del Cuadrante Mágico para Plataformas de Desarrollo de Aplicaciones Móviles. SAP es un acrónimo de Sistemas, Aplicaciones y Productos. El producto más popular de SAP AG es el SAP ERP (del inglés Enterprise Resource Planning). El ERP es un producto informático de gestión empresarial que integra todas las líneas de negocio de una compañía, como por ejemplo finanzas, contabilidad, logística, producción, recursos humanos, gestión de calidad, control de proyectos, etc. Estos sistemas de gestión de información corporativa automatizan por tanto muchos de los procesos de negocio asociados a los aspectos operativos o productivos de una empresa. La principal ventaja de los sistemas ERP es que tienen un componente modular que permite adaptar el sistema a las necesidades concretas de cualquier empresa, permitiéndoles que instalen y configuren tan solo el módulo que necesiten. Por mencionar algún punto débil podríamos decir que la implementación de las adaptaciones sobre el sistema base tiene un alto coste económico. 1 Sitio web SAP A.G. 2 Gartner es una empresa consultora y de investigación de las tecnologías de la información Conocida mundialmente por sus análisis de mercado y de sectores. 2 P á g i n a

33 En nuestro proyecto utilizaremos la plataforma SAP R/3. Este sistema, como todo ERP, consiste en integrar diferentes áreas funcionales del negocio de una compañía y unificarlas en una única herramienta Estado de la cuestión. Antecedentes y alternativas Como ya hemos visto, en la actualidad, existe una gran predisposición por parte de los trabajadores a utilizar dispositivos móviles, tales como iphone, ipad, Blackberry o Android durante su desempeño profesional. Esto podemos creer que tiene sentido tan solo para aplicaciones de servicios del negocio, tales como financieras, de manufacturación, balances de costes, etc. Sin embargo, son cada vez más las empresas que asocian la productividad del empleado con su satisfacción personal y el contacto con su trabajo en la compañía. Es por esto que las aplicaciones de recursos humanos están empezando a aparecer. A continuación vamos a mencionar algunas de las soluciones que existen en el mercado SAP y que se aproximan a la solución que pensamos plantear con este proyecto: SAP App Mobile para RRHH HR Renewal 1.0 Aplicaciones Sap Fiori 3 P á g i n a

34 Sap App Mobile para RRHH En estas aplicaciones el usuario puede tener acceso a información corporativa y a un amplio rango de actividades relacionadas con los recursos humanos. Por ejemplo, un empleado puede acceder a la estructura organizativa de su empresa y buscar datos de contacto según sea necesario. Puede consultar calendarios para ver días de vacaciones disponibles y hacer la petición desde su teléfono. Otra función muy útil es capturar facturas de viajes o gastos de negocio con el dispositivo y tramitar la solicitud de abono casi en tiempo real. Y así otras muchas funciones, algunas más básicas, tales como su nómina, sus gastos, los tiempos de trabajo, etc. A continuación se presentan algunas de las aplicaciones móviles para RRHH que SAP tiene en el mercado: SAP Employee Lookup SAP HR Approvals SAP Interview Assistant SAP Leave Request SAP Manager Insight SAP Timesheet SAP Travel Expense Approval SAP Travel Receipt Capture A continuación vamos a explicar a modo de ejemplo cómo funcionan y de qué constan dos de ellas: SAP HR Approvals Esta aplicación facilita a los managers y gerentes de la compañía aprobar y dar el visto bueno a las solicitudes que realizan sus empleados. Por ejemplo viajes, 4 P á g i n a

35 vacaciones, actividades, etc. Es una manera rápida y sencilla de lanzar el inicio de numerosos procesos SAP Travel Receipt Capture Esta es una de las aplicaciones relacionadas con la gestión de viajes. Lo que hace básicamente es permitir a los empleados desplazados grabar todos sus gastos y facturas a través de su dispositivo móvil. Todo esto reduce los trámites administrativos y facilita mucho la tarea tanto de empleados como de administradores. Es una forma simple de reportar las facturas al sistema desde el teléfono personal HR Renewal 1.0 HR Renewal es un producto de SAP que incluye funcionalidad del módulo HCM, por ejemplo e-learning, Employee and Manager Self-Service, Gestión Organizativa, y algunos otros procesos del módulo de recursos humanos. Esta plataforma fue lanzada al mercado en 2012 y trata de dar una mejor experiencia de usuario a los trabajadores; en términos de armonía, intuición y facilidad de uso. Nació de la necesidad de crear y lanzar procesos RH a bajo coste y no necesariamente desde el UI estándar de SAP, sino del de la elección del usuario. HR Renewal 1.0 incorpora procesos de empleado y de manager, está diseñado para escalar a nuevas tecnologías y reduce costes técnicos de infraestructuras. Tiene hasta cuatro paquetes de características integrados. 3 Para más información de la herramienta HR Renewal 1.0, consultar: 5 P á g i n a

36 Ilustración 3: HR Renewal Aplicaciones Sap Fiori Sap Fiori 4 es un conjunto de aplicaciones que representa el nuevo paradigma de SAP de experiencia de usuario. Estas aplicaciones comparten un interfaz, un lenguaje de diseño y una infraestructura técnica común. Utiliza elementos UI atractivos e interactivos que pueden ser utilizados en cualquier tipo de dispositivo sin un esfuerzo adicional de desarrollo. Las aplicaciones Fiori se centran en las actividades más comunes y críticas de los usuarios. Algunas de las características de este tipo de desarrollo son: Role-based: el interfaz de usuario está orientado a cómo la gente trabaja, en lugar de forzar a la gente a cambiar el modo en que trabaja. 4 Para más información de Sap Fiori Apps, consultar: y 6 P á g i n a

37 Responsive design: aplicaciones basadas en la filosofía de cualquier tamaño, cualquier dispositivo, cualquier versión. Se trata de garantizar la misma experiencia de usuario independientemente del canal de uso. Simple: el diseño está más centrado en la experiencia de usuario y no en añadir muchas características o funcionalidad lógica. Coherent: incorpora las mejores prácticas de desarrollo a todos los interfaces Fiori. Instant value: estas aplicaciones tienen una barrera de adaptación muy baja, que permite a los desarrolladores adaptarlas, y a los usuarios personalizarlas. Ilustración 4: Sap Fiori, principios de diseño En esta primera versión, se incluyen 25 aplicaciones, para 4 roles de usuario: manager, empleado, representante de ventas y comprador. Con aplicaciones para solicitar/aprobar vacaciones, gastos de viajes, horas, pedidos, ver el recibo de nómina, el estado de un pedido o una factura 7 P á g i n a

38 Ilustración 5: Algunas aplicaciones Fiori La vista de las aplicaciones Fiori en los tres dispositivos habituales se muestra en la siguiente figura: Ilustración 6: Vista Apps Fiori en varios dispositivos En nuestro proyecto vamos desarrollar una nueva aplicación Fiori con una funcionalidad nueva que no exista entre las aplicaciones ya existentes. Se va por tanto a hacer uso del SAP Fiori Toolkit. Es una herramienta de interfaz de usuario para desarrolladores que facilita el consumo de modelos OData vía SAP NetWeaver Gateway. Es un plugin para el IDE Eclipse que simplifica notablemente el proceso de desarrollo de las aplicaciones. 8 P á g i n a

39 1.3. Motivación En la sociedad empresarial actual queda bastante patente la necesidad de movilizar los datos de cualquier proceso de negocio. De esta manera se aumenta la productividad del empleado y se favorece la interacción en tiempo real entre los grupos de trabajo y las máquinas. En este proyecto nos centraremos en movilizar los datos del módulo de recursos humanos. Por qué puede interesar movilizar los datos de este módulo en concreto? A lo largo de los últimos años hemos presenciado y experimentado en muchos casos como los trabajadores se han convertían en dependientes de la tecnología móvil para manejar su vida profesional. Por tanto, las funciones de gestión de personal se vuelven cruciales para el negocio. Pérdidas de tiempo, cierre de plazos, o demoras en las solicitudes pueden resultar en pérdida de productividad y bajo rendimiento del equipo. Si los administradores o los gerentes son capaces de buscar, ver perfiles, dar de alta permisos, iniciar flujos de trabajo, etc, podemos estar hablando de un aumento de la capacidad productiva de los empleados y del rendimiento global empresarial. De acuerdo a David Ludlow, vicepresidente de Solutions Management de SAP AG, y experto en el área de SAP HCM, existen tres principales beneficios que se derivan de las aplicaciones móviles asociadas a procesos de recursos humanos 5 : - La movilidad ayuda en la fidelización de los empleados y en su reclutamiento. - La movilidad acelera los flujos de trabajo y proceso en recursos humanos. - La movilidad compromete a los empleados. 5 Para leer el artículo completo de David Ludlow: 9 P á g i n a

40 Ya hemos visto que existen aplicaciones para gestionar diferentes módulos dentro del área de recursos humanos. Algunas de ellas son gestión de viajes, de horarios, de facturas, etc. Nuestra aplicación tiene que ver con la administración y la formación de los empleados. Es decir, se gestionarán los cursos de aprendizaje disponibles, las cualificaciones necesarias para una posición, el perfil del empleado, sus datos personales, etc. Esta aplicación puede suponer una gran ventaja pues además incluye oportunidades de formación, oferta de cursos según el puesto y el perfil del empleado, etc. Por otro lado, al movilizar los datos de nuestros empleados se favorece el contacto entre trabajadores dentro de la misma compañía y el alejamiento de las rígidas aplicaciones de escritorio. De esta manera el trabajo fluye más dinámicamente y se puede contar con los empleados mejores preparados para una tarea en concreto. Por tanto, en esta parte relacionada con la formación será donde se centre nuestro proyecto. 10 P á g i n a

41 2. Estado de la técnica 2.1. Sap R/3 En este proyecto vamos a desarrollar una solución móvil para gestionar información perteneciente a la plataforma SAP. Para ello, utilizaremos el sistema integrado 6 SAP R/3. La "R" de SAP R/3 hace referencia a la condición de tiempo real. El número 3 está relacionado con la arquitectura de programación por capas: base de datos, servidor de aplicaciones y cliente ligero (SAP GUI). El R/3 es en definitiva un ERP (Enterprise Resource Planning) altamente modular y que ofrece soluciones estándar para las necesidades de una compañía. A continuación se presentan los módulos que componen el sistema R/3: Finanzas (Rojo) FI: (Financial) Finanzas. CO: (Controlling) Costos y Control. Ilustración 7: Módulos del sistema R/3 6 Un sistema integrado implica que una vez que la información es almacenada, está disponible a través de todo el sistema, facilitando el proceso de transacciones y el manejo de los datos. 11 P á g i n a

42 AM: (Assets Management) Control Activos. PS: (Project System) Sistema de proyectos. Logística (Verde) SD: (Sales and Distribution) Ventas y Distribución. MM: (Materials Management) Gestión de Materiales. PP: (Production Planning) Planificación de la producción. QM (Quality Management) Aseguramiento de calidad PM (Plant Maintanance) Control de pisos Funciones multiaplicaciones (violeta) WF: Workflow IS: (Industry Solutions) Solución vertical para industrias (Químicas, AeroEspaciales, Mecánicas, etc). Gestión Recursos Humanos (Amarillo) HR: (Human Resources) Recursos Humanos. Además de estas funciones estándar, el sistema SAP R/3 permite a los clientes desarrollar funciones sobre el sistema, adaptándolo a los requerimientos individuales de la compañía. En otras palabras, permite la personalización (customizing en términos SAP). El desarrollo del sistema R/3 ofrece a los usuarios su propio lenguaje de programación de cuarta generación (ABAP/4), creado especialmente para necesidades comerciales. 12 P á g i n a

43 Las principales características del sistema son: Parametrizabilidad: esta es la característica más importante del sistema. Se trata de un software estándar pero que dispone de herramientas específicas para la adaptación precisa a las necesidades de la empresa. Estas herramientas, englobadas en lo que se conoce como el customizing, permiten amoldar los procesos de negocio establecidos en el estándar a la manera de trabajar de cada empresa. Portabilidad: el software SAP R/3 se caracteriza por su adaptabilidad a distintos tipos de hardware, sistemas operativos y RDBMS (Relational Data Base Management System). Algunos sistemas operativos que soportan SAP R/3 son: Unix, sistema operativo multitarea y multiusuario. Open VMS (Open Virtual Memory System). MPE (Multi-Programming Executive), sistema operativo de tiempo real orientado a negocios. Propiedad de Hewlett-Packard (HP). Windows NT, familia de sistemas operativos de Microsoft. Algunas bases de datos compatibles con el sistema R/3 son: Informix, de IBM Oracle Software AG Sybase Escalabilidad: se permite la adición de nuevos equipos en cualquiera de sus 3 niveles para acomodarse a los requerimientos dinámicos del sistema. Apertura: todos los datos están almacenados en tablas que son accesibles sin necesidad de instrucciones complejas de recuperación de datos. 13 P á g i n a

44 La configuración de SAP se realizará en este proyecto a través de dos herramientas que proporciona el mismo sistema: Guía de Implementación (IMG): es una estructura jerárquica que facilita la parametrización del sistema SAP estándar a las necesidades de la empresa en concreto. Se utiliza para estructurar y organizar las fases de parametrización. Desde la IMG se accede a tablas, programas, se crean la estructura de la compañía, etc. Ilustración 8: Herramienta guía IMG Acceso directo a tablas a través de la transacción SM31: desde la vista de esta transacción se puede acceder de forma lógica a las tablas y ajustar el sistema a las necesidades de la empresa de la misma manera que desde la IMG. Sin embargo, es más complicado, puesto que esta herramienta obliga a conocer el nombre técnico de todas las tablas que necesitemos configurar. Se seguirá este proceso cuando se necesite consultar algún dato concreto o variar alguna de las entradas de cualquier tabla. 14 P á g i n a

45 Ilustración 9: Herramienta transacción SM Arquitectura SAP R/3 La arquitectura del sistema R/3 es una arquitectura multicapa de tipo cliente/servidor. Está basada en tres capas, de abajo a arriba: base de datos, aplicación y presentación. Esta estructura se fundamenta en la repartición de las tareas que debe realizar el sistema entre las tres capas. Capa de base de datos: generación, almacenado y recuperación de los datos empresariales. Son bases de datos relacionales que usan exclusivamente comandos del lenguaje SQL. Se dispone de 2 tipos diferentes de SQL: el Open SQL (extensión de lenguaje de programación ABAP/4) y el Native SQL (SQL nativo del sistema de base de datos que tengamos por debajo de nuestro SAP). Capa de aplicación: servicios para el manejo de la lógica de aplicación implementada. Destacamos aquí el servicio que para nosotros es el más importante, el Gateway. Este servicio se utiliza para realizar tareas que se extienden más allá de la instancia local. Lo utilizaremos para llevarnos las estructuras de datos desde el sistema R/3. 15 P á g i n a

46 Capa de presentación: servicios de maquetación para la implementación del GUI (Graphical User Interface). Servicios de ayuda, de botones, barras de tareas, valores posibles de entrada, etc. Ilustración 10 : Arquitectura del sistema R/ Módulo SAP HCM En este proyecto nos centraremos en la información del módulo de recursos humanos (HR), también llamado HCM (Human Capital Management). Con este módulo se pueden gestionar todas las operaciones relacionadas con los recursos humanos de una organización. Entendemos por organización una empresa individual que cuenta con diferentes departamentos como finanzas, I+D, RRHH, etc. Para cualquier organización los empleados son considerados como uno de los activos más importantes y valiosos. Por tanto, el sistema que gestione los datos de los trabajadores debe garantizar integridad, fiabilidad y seguridad. La tarea principal del módulo HCM es reproducir la jerarquía organizativa de la empresa, el almacenamiento de los datos de personal, relaciones entre empleados, y evaluar el plan de organización. Estas son las principales características del módulo SAP HCM: 16 P á g i n a

47 Es un soporte intuitivo para gestionar procesos de personal, gestión del talento y organización de lo conocido como workforce. Ayuda a fidelizar al personal con talento, mejorar la satisfacción del empleado, y aumenta la moral de la plantilla con las posibilidades de reclutamiento on-line (e-recruiting), aprendizaje on-line (e-learning) y soporte auto-servicio (selfservice support). Gestiona cambios de personal y de organización. Optimiza procesos de nómina. Los procesos o submódulos principales que componen el módulo SAP HCM son: PA (Personal Administration) Administración de personal. o Seguimiento de datos maestros, nóminas, remuneraciones, horarios, etc. PD (Personal Development) Desarrollo de Personal. o Formación de cada empleado. Cualidades y tareas del trabajador en comparación con los requisitos de su puesto de trabajo. Desarrollo de planes de formación y planes de carrera. PY (Payroll) Cálculo de la Nómina. o Evaluación de los pagos y salarios a los empleados. PT (Personal Time) Gestión de Tiempos. o Se procesan los horarios de trabajo y el absentismo; y se evalúa el impacto en el salario bruto. Otros procesos que complementan el módulo SAP HCM son: ECM Gestión de la Remuneración. PCP Planificación de Costo del Personal. EDD Evaluación del Desempeño. PE Gestión de Eventos. E-Recruiting. 17 P á g i n a

48 TM (Transport Management) Gestión Transportes ESS Employee Self-Service MSS Manager Self-Service En este proyecto nos centraremos sobre todo en los procesos de PA (Administración de personal) y PD (Desarrollo de personal) Estructuras en Recursos Humanos El sistema de gestión de recursos humanos permite evaluar los datos de empleado de forma flexible y desde todos los puntos de vista de la estructura organizativa de la empresa. Para ello la estructura empresarial global se subdivide en estructuras de organización. Hay tres estructuras diferenciadas: Estructura de la empresa Estructura de personal Estructura organizativa A lo largo del proyecto trabajaremos con estas tres estructuras constantemente por lo que procedemos a explicar brevemente sus conceptos y los elementos que las componen: 18 P á g i n a

49 Estructura empresarial La estructura de la empresa está basada en los conceptos de mandante, sociedad, división de personal y subdivisión de personal. Un mandante es una unidad independiente a nivel jurídico y de organización. No existe intercambio de datos ni de empleados entre mandantes. Es una forma de aislar los datos de personal contra accesos no autorizados. La sociedad es una entidad independiente, con contabilidad cerrada y balances propios. Representa el nivel máximo dentro de la estructura interna de la empresa. Una división de personal es una entidad específica de la gestión de personal. Es la subunidad más directa dentro de una sociedad y debe ser unívoca dentro del mandante. Ilustración 11: Estructura de la empresa Las subdivisiones de personal son una subunidad más dentro de una división de personal. En este nivel es donde realmente se asignan empleados a posiciones. 19 P á g i n a

50 Estructura de personal La estructura de personal divide a los empleados en agrupaciones en función de factores relevantes para la gestión de tiempos, cálculo de nóminas, planes de horarios, etc. Destacamos los conceptos de áreas de personal y grupos de personal. Son dos niveles en vertical. El nivel más alto lo constituye un grupo de personal; y el inferior, un área de personal. El grupo de personal efectúa una división de los empleados en varias categorías en función de la vinculación que haya entre el trabajador y la empresa. Es decir, en la medida que el trabajador contribuye a la compañía con su trabajo. Ejemplos de grupos de personal podrían ser activos, externos, pensionistas, etc. Las áreas de personal diferencian a los empleados por su estatus dentro de la empresa. Eso es, que los activos (grupo de personal), pueden ser empleados en formación, asalariado por horas, colaborador, etc. Todas las características de control de la estructura de personal se definen a nivel de área de personal Estructura organizativa La estructura organizativa se basa en un plan de organización que proporciona un modelo completo del entorno personal y estructural de la empresa con jerarquías y organigramas confeccionados claramente. El plan de organización es la base de la gestión de organización y se sirve de elementos que se denominan objetos. Los objetos más importantes son las unidades organizativas, las funciones y las posiciones; pero también son objetos los centros de 20 P á g i n a

51 coste, las personas o las tareas. Por tanto, el plan de organización se define con ayuda de las unidades organizativas y de las posiciones. Las unidades organizativas describen las distintas entidades empresariales que existen en la compañía. Deben estar obligatoriamente unidas a un plan de organización. Varias unidades organizativas y sus relaciones internas forman la estructura jerárquica de la empresa. Estas unidades tienen que estar vinculadas también a un centro de costes. Las funciones o trabajos son clasificaciones generales de las tareas que se desempeñan dentro de la empresa. Es una categorización de responsabilidades. Las funciones tienen asignados requisitos asociados al desempeño de ese puesto de trabajo. Al crear una función, se deben definir el número de posiciones que necesita para cubrirse. Las posiciones son asignaciones de empleados individuales en la empresa. Heredan las tareas de la función correspondiente. Las posiciones están directamente vinculadas con personas, a diferencia de las funciones, que están relacionadas con las posiciones. En otras palabras, varias posiciones cubren una función y una posición la cubren una o más personas. Las posiciones por tanto pueden estar ocupadas al 100%, parcialmente ocupadas o vacantes. Los centros de coste se relacionan con unidades organizativas y con posiciones. Tienen que ver con gestión financiera. Como hemos dicho, las personas son objetos que ocupan posiciones dentro de la estructura organizativa. Es decir, son empleados. Los datos maestros de las personas se actualizan en Administración de Personal (PA) y están conectadas con un plan de organización a traves de la asignación a su posición. La información se guarda en estructuras llamadas infotipos. En posteriores secciones desarrollaremos el término infotipo. 21 P á g i n a

52 En la siguiente ilustración vamos a ver cómo se daría de alta en entorno gráfico a un empleado. Como se observa en la parte superior, hay que asignarle a una estructura de empresa, con sociedad, division de personal y subdivisión; a una estructura de personal, especificando grupo y área de personal; y a una estructura organizativa, que es el plan de organización, la unidad organizativa y posición relacionadas con el empleado. Ilustración 12: Estructura organizativa, de empresa y de personal Ya hemos comentado anteriormente que la gestión de recursos humanos tiene varios módulos que controlan y manejan diferentes ámbitos: PT (tiempo personal), PY (cálculo de nóminas), TM (gestión de transportes), e-recruiting, etc. A continuación vamos a centrarnos en explicar los dos módulos que vamos a tocar en este proyecto, PA (Administración de Personal) y PD (Desarrollo de Personal). 22 P á g i n a

53 Administración de personal (PA) Mediante los procesos de PA, el sistema permite fijar jerarquías organizativas y relaciones entre los empleados y almacenar y gestionar los datos del empleado en el sistema. A continuación se presentan los conceptos y procesos básicos que vamos a utilizar para entender cómo funciona este submódulo de SAP HCM. Infotipos y subtipos Medidas de personal Contratación. Entrada de datos maestros Infotipos y subtipos Los campos de datos se agrupan según criterios de contenido para formar grupos de datos o unidades de información. En gestión de personal, a esto es a lo que llamamos infotipos. Para el usuario final los infotipos aparecen como imagen de entrada de datos maestros. Los infotipos son agrupaciones lógicas de campos de datos que se agrupan según criterios de contenidos. Definen características particulares de un objeto dentro de un periodo de validez que se define dentro del infotipo. Las fechas de validez determinan la vida del objeto. Los subtipos sirven para realizar una división inferior de los registros de datos de infotipo. Se puede proceder a esta clasificación para facilitar la visión general, o bien porque se desea asignar distintas características de control, como enlaces temporales, a los diferentes subtipos del mismo infotipo. Además, puede crear historiales independientes para cada subtipo. Un ejemplo de subtipo sería Miembro de la familia del infotipo Familia. 23 P á g i n a

54 Medidas de personal Los datos de empleado deben mantenerse al día. Después de contratar a un empleado, es posible que surjan circunstancias que requieran la entrada de datos nuevos o la corrección de los existentes. Cuando decimos que estamos actualizando los datos maestros lo que estamos haciendo en realidad es tratar los infotipos asociados. Existen tres formas de tratamiento distinta de infotipos, pero la más importante para nosotros son las medidas de personal. Las medidas de personal son acciones que se ejecutan sobre el sistema y que requieren la actualización de varios infotipos. Cuando se aplica una medida de personal a un empleado el sistema va guiando al usuario por todos los infotipos relevantes para que los actualice. De esta manera se garantiza que toda la información relevante para la operación se introduzca y actualice en el sistema R/3. Las medidas de personal son muy extensas y variadas. Algunos ejemplos pueden ser contratación, dar de baja, traslado, fallecimiento, etc. En la siguiente ilustración vemos la secuencia de infotipos a actualizar al aplicar la medida Reasignación organizativa. A esta operación se le llama ejecutar infogrupo. Ilustración 13: Secuencia de infotipos al aplicar una medida de personal 24 P á g i n a

55 Contratación. Entrada de datos maestros. El objetivo más importante de la gestión de datos maestros en Recursos Humanos consiste en introducir datos de empleado para la gestión, la entrada de tiempos y el cálculo de nómina. La forma más rápida de contratar a un trabajador es aplicándole una medida de contratación. Se introducen los datos maestros y se graban los datos en los infotipos relevantes. Cuando se da de alta una persona, los infotipos más habituales que se rellenan y actualizan son los siguientes: Infotipo 0000: Medidas: este infotipo graba en log la ejecución de las medidas de personal que se le han aplicado al candidato. Guarda también los motivos de la medida. Infotipo 0001: Asignación organizacional: se ocupa de la incorporación del empleado en la estructura organizativa (sociedad, división y subdivisión) y en la estructura de personal (grupo y área de personal) Infotipo 0002: Datos personales: almacena los datos personales del empleado. Nombre, DNI, estado civil, etc. Infotipo 0006: Direcciones: este infotipo no es muy relevante pero guarda las direcciones de localización del empleado. Infotipo 0007: Horario de trabajo teórico: en este infotipo se introducen el tipo de plan de horario de trabajo del empleado. Se indica también si se evalúan las contabilizaciones de tiempos del empleado y si el empleado trabaja a tiempo parcial. 25 P á g i n a

56 Infotipo 0008: Emolumentos básicos: en este infotipo se indica la retribución básica del empleado y también se registran las actualizaciones del sueldo que se le efectúen al trabajador. En nuestro proyecto, cuando contratemos personal, la secuencia de infotipos a parametrizar es 0001, 0002, 0006 y Desarrollo de personal (PD) El principal objetivo del módulo de desarrollo de personal es cualificar a los empleados para que cumplan con los requisitos actuales y futuros de su posición. Todo esto implica la planificación de planes de perfeccionamiento para el desarrollo profesional de los empleados. El desarrollo de personal permite garantizar que una empresa disponga de todas las cualificaciones y aptitudes necesarias en todos los campos. Por una parte, el desarrollo de personal se basa en las cualificaciones y aptitudes que necesita una empresa. Por la otra, también se tienen en cuenta las necesidades y aptitudes de los distintos empleados. Para poder evaluar el desarrollo de los empleados debemos hacer un análisis de la empresa y definir objetivos. Estos objetivos deben dirigirse a los requisitos actuales y futuros. La idea consiste en confrontar las cualificaciones de cada empleado con los requisitos de cada posición, y de esta manera hacer una evaluación de perfiles. Según los resultados de la comparación de perfiles se puede optar por distintas medidas de perfeccionamiento y de desarrollo. Las principales planificaciones son plan de carrera, plan de sucesión, y plan de desarrollo. 26 P á g i n a

57 Los principales componentes del módulo de Desarrollo de Personal son Cualificaciones y requisitos, Planificación de carrera y de sucesión, Planes de desarrollo y Sistemas de calificación Cualificaciones y requisitos El primer paso que debemos seguir es definir la diferencia entre cualificaciones y requisitos. Las cualificaciones hacen referencia a las aptitudes, habilidades o conocimientos que posee una persona. El término requisitos hace referencia a las aptitudes, habilidades o conocimientos que se necesitan para ocupar una posición o un puesto de trabajo. En el sistema R/3 se puede definir un catálogo de cualificaciones que son todos los conocimientos y aptitudes que resultan de interesa para una empresa. Será desde el catálogo de cualificaciones desde dónde asignaremos las habilidades tanto a posiciones como a empleados. A continuación vemos en una ilustración un ejemplo de catálogo: Ilustración 14: Ejemplo de catálogo de cualificaciones 27 P á g i n a

58 Es muy importante que los requisitos y las cualificaciones se puedan comparar entre sí. Esto constituye una condición previa para comparar los perfiles de posición vs trabajador. Este es el motivo por el cual se utiliza el mismo catálogo para organizar tanto cualificaciones como requisitos. Es importante también mencionar las escalas de calidad. Esto es una escala de valores que evalúa el nivel de asimilación de una cualificación RFC (Remote Function Call) En SAP existe lo que se llama módulos de funciones. Son objetos que realizan operaciones que pueden ser utilizadas en varios programas. Al crear un módulo de función con el código que realiza una operación, se evita tener que repetirlo en todos los programas que realicen esa operación añadiendo en ellos una llamada al módulo de función. Hay dos tipos de módulos: Normal: Módulo de función normal. Remote Function Call (RFC): módulos de ejecución remota. Estas funciones pueden ser ejecutadas desde otros sistemas externos a SAP. Una RFC es una interfaz para la comunicación entre un sistema SAP y otro sistema distinto a través de TCP / IP. Las RFCs se relacionan con el sistema SAP R/3 a través del lenguaje de programación ABAP y proporcionan una forma para que un programa externo (escrito en lenguajes como PHP, ASP, Java, C, C++) pueda usar los datos devueltos por el sistema de back-end. De esta manera, no solo se lleva a cabo la obtención de datos desde el servidor, sino que también se pueden insertar o actualizar datos en los registros del sistema. SAP puede actuar como cliente o servidor en una llamada RFC. 28 P á g i n a

59 En nuestro proyecto utilizaremos las RFCs para obtener datos del sistema y posteriormente servírselos al servicio de Gateway, que los enviará a la aplicación. SAP dispone de un gran número de módulos de función predefinidos que se pueden utilizar en nuestros programas, a las que se añadirán los que se desarrollen a medida. Los módulos de función pertenecen a grupos de funciones, que los agrupan según su funcionalidad. Conceptos básicos que se deben manejar para trabajar con RFCs: Los imports: parámetros de entrada a la función. Los exports: parámetros de salida de la función. Las tablas: se pueden traspasar tablas por referencia en la llamada al módulo de función. Las exceptions: Las excepciones son una serie de errores predefinidos en los módulos de función que pueden devolver como valor de retorno de su ejecución en la variable del sistema SY-SUBRC. Código fuente: programación en código ABAP de la lógica de la función Sap NetWeaver Gateway Un servicio de gateway es una tecnología que permite conectar de una manera sencilla dispositivos, entornos o plataformas con algún tipo de software de back-end (ERP, CRM, etc). La comunicación entre el gateway y cualquier dispositivo se efectúa vía HTTP/HTTPS La plataforma SAP NetWeaver que vamos a usar se basa en un stack ABAP instalada bajo dos add-ons: el UI add-on que permite usar las librerías de SAPUI5; y el SAP NetWeaver Gateway que permite construir servicios de datos OData. 29 P á g i n a

60 El SAP NetWeaver Gateway permite por tanto exportar los servicios del backend de SAP (utilizando el protocolo conocidos como OData/ATOM). A partir de estos servicios estándar, es posible desarrollar una aplicación que acceda los servicios SAP desde cualquier dispositivo, incluyendo aquellos que son móviles. Al ser una arquitectura abierta, es posible utilizar diferentes herramientas de desarrollo disponibles en el mercado Servicio OData En el Sap NetWeaver Gateway se debe crear un servicio de Gateway que sea accesible desde fuera, vía HTTP. Para crear un nuevo servicio utilizando el Gateway de SAP hay que seguir una serie de fases: 1. Construir el modelo de datos: se trata de definir los entity types y los entity sets. a. Un entity type es una estructura de datos a la que el servicio podrá acceder. Pueden crearse de cero o a partir de estructuras ya definidas en el sistema. En este caso se importarán a través de las RFCs que tenemos definidas en el sistema. Cada entity quedará definido con una serie de campos o properties que son los campos de información que deseamos leer del servicio de cada uno de los entity types. b. Los entity types definen la estructura que caracteriza una orden, sin embargo la colección de órdenes u objetos son accedidos a través de sus entity set o colecciones. Los entity types y entity sets deben tener una relación de 1 a 1. Al definir un entity set se debe definir tanto su entity type como las acciones que podremos realizar con él; Crear, Modificar, Borrar 2. Generar los objetos. a. ZCL_Z_SERVICIO_MPC: Es el Master Provider Class. Contiene la estructura que acabamos de definir. El $metadata del servicio está contenido en esta clase. 30 P á g i n a

61 b. ZCL_Z_SERVICIO_DPC: Es el Data Provider Class. Esta clase contiene la información necesaria para realizar las operaciones sobre las distintas colecciones del modelo. 3. Activar el servicio. Desde la transacción /IWFND/MAINT_SERVICE 4. Redefinir métodos en el DPC. a. La clase DPC está formada por varios métodos que se generan de manera automática y que debemos redefinir si queremos que desde fuera se puedan ejecutar ciertas acciones sobre las colecciones. Estas operaciones pueden ser filtrado, actualizaciones, etc. Para nuestro proyecto, necesitamos definir filtros por los parámetros por los que se quiere establecer las búsquedas desde la aplicación. De manera que cuando se efectúa una búsqueda en la aplicación, no se ejecuta según código javascript, sino que se conecta al sistema y busca la lógica ABAP en el servicio de gateway. Una vez activado y configurado el servicio en su totalidad se proporcionará un enlace mediante el cual, a través del navegador, se puede acceder a los datos del modelo. Un ejemplo de un servicio de gateway se ve en la siguiente imagen: Ilustración 15 : Ejemplo de servicio de gateway 31 P á g i n a

62 Si hacemos click en llamar al navegador se nos proporcionará una url, que es el enlace al servicio OData al que accederemos desde el exterior. Este servicio ya trae los datos del modelo. Un ejemplo de enlace al servicio es: SAPUI5 El SAPUI5 es un kit de herramientas que provee SAP para presentar la información que proviene del back-end en formato HTML5. Esta tecnología combina las ventajas del código abierto (HTML5, CSS3 y Javascript), y se puede utilizar en distintos dispositivos, como smartphones con sistemas operativos Android o ios, y en múltiples navegadores como Firefox, IExplorer y Chrome, entre otros. De esta manera se pueden construir aplicaciones simples, orientadas al usuario SAP en un dispositivo móvil, con una presentación atractiva, en poco tiempo y con costos razonables. En este proyecto haremos uso de esta herramienta para programar nuestra aplicación. Además, como ya mencionamos, se hará uso del Fiori Toolkit, por lo que nuestra interfaz de usuario será muy similar a la interfaz de las aplicaciones de Fiori. Dos puntos básicos sobre los que se sustenta la programación sobre SAPUI5 son el MVC (Modelo Vista Controlador) y el Data Binding. 32 P á g i n a

63 Modelo Vista Controlador (MVC) SAPUI5 basa el desarrollo de sus aplicaciones en el concepto del Modelo Vista Controlador (MVC) 7, y es lo que vamos a seguir en este proyecto. Gráficamente se puede observar en la siguiente imagen: Ilustración 16: Modelo Vista Controlador En nuestro proyecto vamos a tener diferentes tipos de archivos: HTML Files: las aplicaciones en SAPUI5 siempre deben contener lo que se denomina bootstrap, que sirve para inicializar el runtime de SAPUI5 incluir librerías, temas, etc. VIEW: en las vistas es donde se implementa el interfaz de usuario de la aplicación. Puede ser archivo XML, Javascript, HTML, o JSON. CONTROLLER Files: cada vista tiene asociado un controlador donde se implementa la lógica de la aplicación SAPUI5. MODEL: SAPUI5 soporta tres implementaciones diferentes de modelos: 7 Más info sobre MVC: 33 P á g i n a

64 Modelo JSON: para datos JSON Modelo XML: datos en formato XML. Modelo OData: orientado a consumir servicios de OData Data Binding Data Binding 8 es una relación de actualización automática entre un modelo de datos y la configuración de la aplicación. Es decir, si el usuario realiza una acción, el modelo de dato se actualiza automáticamente en función de los parámetros de entrada del usuario. Por ejemplo, para añadir en SAPUI5 el modelo OData que tenemos generado en el back-end se programa en muy pocas líneas de código: // crea una instancia de modelo OData // url es el enlace que nos proporciona el servicio de Gateway al modelo de datos var omodel = new sap.ui.model.data.odatamodel(url,user,pass); // añadir el modelo al core de la aplicación sap.ui.getcore().setmodel(omodel, NombreModelo ); De esta manera ya se tienen los datos del modelo en la aplicación. La manera de acceder a ellos en la vista XML es a través del data binding, de la siguiente manera: 8 Más info Data Binding: 34 P á g i n a

65 <Text text="{nombremodelo>/propiedad} "/> 2.6. SAP Fiori A continuación se presenta brevemente cómo es el interfaz de las aplicaciones Fiori y cómo se lleva a cabo el data binding, es decir, el proceso que establece la conexión entre el UI (interfaz de usuario) de la aplicación, y la lógica de negocio. Cabe mencionar que para hacer uso de Fiori Toolkit es necesario instalar el plugin en el IDE Eclipse. La apariencia del proyecto Fiori es la siguiente: Ilustración 17: Ejemplo de proyecto Fiori La carpeta principal del proyecto generado es la carpeta WebContent. Aquí están contenidos todos los archivos HTML, Javascript y CSS que se necesitan para correr la aplicación. 35 P á g i n a

66 Vemos que el archivo index.html es generado de manera automática. Aquí es dónde se deben declarar las librerías y los paquetes de los que se va a hacer uso. Esto se define en la etiqueta de bootstrap, el script más importante del index.html: Ilustración 18 : Etiqueta bootstrap (index.html) En la carpeta principal del WebContent tendremos todas las vistas y controladores que formen nuestra aplicación. Estas vistas pueden ser XML, JS, o HTML. Las aplicaciones Fiori despliegan al inicio un conjunto de tiles, o iconos de acceso rápido, en función del role que tenga el usuario identificado. Los tiles son básicamente un menú de usuario que identifica a simple vista las actividades que se pueden realizar sobre la aplicación y permita un rápido acceso al contenido que se desea ver clicando el icono. En la siguiente imagen vemos un dispositivo móvil con tres tiles para el rol empleado : 36 P á g i n a

67 Ilustración 19: Menú usuario Fiori Una vez se accede a cada actividad del menú de usuario se puede hacer uso de numerosos controles y fuentes propios del toolkit de Fiori. La pantalla más común y utilizad es la pantalla máster-detail. A la izquierda se presenta la visual del máster, y a la derecha el detail. La navegación se hace de tal manera que cuando se selecciona uno de los ítems del máster, los detalles se muestran instantáneamente en la pantalla detail, dónde se puede navegar por los detalles del ítem seleccionado. Ilustración 20_ Master-Detail page. Fiori 37 P á g i n a

68 Estos son algunos de los controles de los que se puede hacer uso para implementar la pantalla máster-detail: Ilustración 21: Controles SAP Fiori 38 P á g i n a

69 3. Definición del proyecto En este capítulo se pretende analizar cuáles son las necesidades que se van a cubrir con el proyecto para poder satisfacerlas de la forma más eficaz posible. En este apartado recogeremos los objetivos que se persiguen y el alcance de la aplicación. Posteriormente se estimarán las fases a seguir a modo de metodología de trabajo y se especificará una planificación temporal Objetivos La finalidad de este proyecto es implementar una solución de movilidad innovadora y eficiente dónde el usuario, que será el gerente responsable de la sociedad, pueda realizar diversas consultas y ejecutar acciones sobre los empleados a su cargo dentro de una organización. Partiendo de esta idea, los principales objetivos del proyecto son los siguientes: ID OBJ-1 OBJ-2 OBJ-3 OBJ-4 OBJ-5 OBJ-6 OBJ-7 OBJETIVO Estudio del sistema SAP R/3 y del módulo de SAP HCM Diseño de una estructura organizativa modelo. Parametrización en el sistema de los módulos necesarios Análisis y diseño de la solución móvil Programación de las RFCs con ABAP Configuración del Sap NetWeaver Gateway Programación de la solución móvil con SAPUI5 Tabla 2: Objetivos 39 P á g i n a

70 3.2. Metodología A continuación se presenta el método de trabajo que se va a seguir para la consecución del proyecto. Las fases o etapas coinciden con los objetivos principales y cada una de ellas se desglosa en tareas a realizar. Se ha añadido al comienzo una fase cero que hace referencia al inicio y primer acercamiento al trabajo y a los sistemas a utilizar. F0. Preparación del proyecto T0. Presentación del proyecto T0. Acceso a sistemas/usuarios F1. Estudio del sistema SAP R/3 y del módulo de SAP HCM T1. Estudio del sistema SAP R/3 y del módulo de SAP HCM F2. Diseño de una estructura organizativa modelo T2. Diseño de una estructura organizativa modelo F3. Parametrización en el sistema de los módulos necesarios T3. Definición de la estructura empresarial - Creación de la sociedad y la división global; divisiones y subdivisiones de personal según el diseño de la compañía. - Es necesario asociar cada una de las divisiones de personal a la sociedad a la que pertenecen. Y de la misma manera asociar las subdivisiones a la división de personal de la que cuelgan. T4. Definición de la estructura de personal - Creación de grupos de personal y áreas de personal. Es necesario asociar los grupos y las áreas de personal. T5. Definición del plan de organización - Definición de todos los elementos jerárquicos de la estructura de la empresa como unidades organizativas y establecer relación de pertenencia entre ellas. - Después de definir la estructura organizativa, debemos asociarla a la estructura empresarial. Esto en términos de parametrización SAP se llama imputación. T6. Definición del plan de ocupación 40 P á g i n a

71 - Consiste en asignar un titular a cada una de las posiciones vacantes de la compañía. Para ello, lo primero es crear funciones y posiciones para los departamentos. Esto son los puestos de trabajo. Después, se deben aplicar medidas de contratación a los empleados para asignarlos a la posición que vayan a ocupar. F4. Análisis y diseño de la solución móvil T7. Estudio de la arquitectura - Estudio de los bloques de trabajo que interactúan en la solución final y definición de cada uno de ellos. T8. Identificación de los procesos y datos a movilizar - Identificación de los datos que queremos movilizar a la aplicación y hacer un estudio de las funciones que se necesitan. F5. Programación de las RFCs con ABAP T9. Programación de las RFCs con ABAP - Las RFCs son funciones programadas en ABAP que se encargan de seleccionar los datos del sistema R/3 y devolver en el formato que indique el programador F6. Configuración del Sap NetWeaver Gateway T10. Configuración del Sap NetWeaver Gateway - Creación de nuestro modelo de datos importando las RFCs que se han programado. - Tendremos un único servicio de Gateway, un único modelo de datos. Sin embargo, las colecciones internas del modelo serán varias, tantas como RFCs hayamos importado al modelo. F7. Programación de la solución móvil con SAPUI5 T11. Prototipado Fiori de la aplicación - Para programar la aplicación de este proyecto, vamos a hacer uso del interfaz de Fiori, por lo que debemos hacer un estudio previo de las pantallas que nos interesan y cómo se van a presentar los datos en el front-end. T12. Importación del modelo de datos a la aplicación 41 P á g i n a

72 - Esto es necesario para poder hacer uso de los datos en el front-end de la aplicación. Para que el navegador no bloquee los datos se debe deshabilitar la seguridad web mediante el comando --disable--web--security. T13. Data Binding - Presentación de los datos de cada una de las colecciones del modelo de datos en el front-end de la aplicación. 42 P á g i n a

73 4. Planificación y estimación económica A continuación se presenta una planificación temporal para la realización del proyecto y una estimación del coste económico aproximado. La duración total del proyecto son 4 meses y la inversión semanal son 40 horas. Para calcular el coste económico de cada fase, hemos asumido 5 roles principales que participarán durante el proyecto. Así mismo, hemos estimado las horas de trabajo de cada rol en cada una de las tareas, teniendo en cuenta las 40 horas semanales, que se deben repartir entre los 5 roles. En la siguiente figura se observa la planificación de cada una de las fases y tareas a lo largo de los 4 meses. En la parte inferior de la figura se encuentran los perfiles con las horas invertidas en cada tarea: Ilustración 22: Diagrama de planificación 43 P á g i n a

74 A continuación vamos a definir las funciones de los 5 roles principales que participan en el desarrollo del proyecto: Gerente: experto en soluciones móviles y en el sistema SAP. Encargado de la gestión global del proyecto y de asegurar la calidad necesaria de los productos elaborados. Vigila el cumplimiento de plazos y realiza un seguimiento continuado. Jefe de Proyecto de Movilidad SAP: responsable de la operativa y la ejecución de todas las fases del proyecto. Se encarga de coordinar la realización de todas las tareas y colabora activamente en el avance del proyecto. Consultor funcional SAP: experto y conocedor del sistema SAP, responsable de la parte técnica y funcional del módulo HCM. Está encargado de la parametrización y configuración del sistema y del análisis y diseño de la solución móvil, así como del estudio de los procesos a movilizar garantizando el alineamiento con el sistema SAP. Programador ABAP/4: encargado del estudio de las rutinas SAP estándar existentes en el sistema y de la programación de las RFCs adicionales que son necesarias. Programador SAPUI5: conocedor del framework de trabajo SAPUI5 así como de la tecnología Sap Fiori. Encargado de dar cobertura a la implementación de la aplicación móvil. 44 P á g i n a

75 En la siguiente ilustración vamos a ver una tabla con los diferentes perfiles que hemos presentado, sus horas trabajadas en el proyecto y sus honorarios. En la casilla inferior derecha, sombreado en verde, vemos la estimación económica final. Ilustración 23: Estimación económica El coste total del proyecto asciende a , P á g i n a

76 46 P á g i n a

77 5. Descripción de la solución 5.1. Diseño de la estructura organizativa modelo A continuación vamos a diseñar cómo será la compañía sobre la que se va a sustentar este proyecto. Debemos definir jerárquicamente las secciones de la empresa e identificarlas con los elementos que componen la estructura empresarial y organizativa de SAP, para posteriormente introducir y generar las estructuras de datos necesarias en el sistema R/3. Nuestra empresa se va a llamar SES (Sap&Enterprise Solutions). Esta máxima jerarquía se corresponde con el concepto de sociedad en SAP. Los departamentos que tendremos son las divisiones de personal. Serán cuatro: logística, HCM, movilidad y finanzas. Si seguimos en la jerarquía hacia abajo encontramos las subdivisiones de personal, que serán entre una y dos por cada división. En la imagen siguiente lo vemos de manera gráfica. Ilustración 24 : Estructura de la compañía modelo SES 47 P á g i n a

78 En la siguiente tabla se observan las funciones y posiciones que va a haber en cada departamento (subdivisión). Div Subdivisión Función Posición LO Control Calidad Consultor Calidad Consultor Calidad Responsable Selección Responsable Selección HCM Depto Selección Responsable de entrevistas Responsable de entrevistas Administrativo Utilities Administrativo Utilities Utilities Asistente Utilities Asistente Utilities Contable Contable FI Depto Costes Responsable de presupuesto Responsable de presupuesto Director Ventas Director Ventas Depto Ventas Comercial Comercial Desarrollador Android Desarrollador Android Desarrollo Desarrollador ios Desarrollador ios MO aplicaciones Consultor cloud Consultor cloud Servicios cloud Experto cloud Experto cloud Leader Leader Tabla 3: Divisiones, subdivisiones, funciones y posiciones 48 P á g i n a

79 5.2. Parametrización SAP La parametrización SAP consiste en la configuración del sistema de acuerdo a las necesidades de la empresa que lo quiere implantar. En nuestro caso, parametrizar es equivalente a definir la empresa en el sistema y dar de alta todos los módulos que la componen. Se establecerá la conexión al sistema SAP contra uno de sus servidores. Como ya hemos dicho, este proyecto se desarrollará en la máquina del laboratorio de Everis. Esto se realiza a través de una conexión en la aplicación del SAP Logon. Ilustración 25: Selección de conexión, Sap Logon Una vez elegimos la conexión deseada, el SAP Logon nos facilita el acceso a través de un usuario y una contraseña. Se elegirá un idioma de trabajo o se dejará el que el sistema nos da por defecto. 49 P á g i n a

80 Ilustración 26: Pantalla de entrada al sistema SAP Cuando se introducen los datos el SAP Logon hace la validación interna del usuario introducido y entra al sistema conectando con el servidor. A continuación se despliega una interfaz gráfica con la que ya se navega por el sistema. Una vez dentro del sistema, vamos ahora a proceder a crear desde la IMG una compañía como la que se ha diseñado. Y a parametrizar sus funciones y procesos del área de recursos humanos. Desde la transacción SPRO se accede a la guía IMG. En la siguiente imagen vemos que desde la guía de implementación se ejecutan todos los procesos que queremos para nuestro proyecto: 50 P á g i n a

81 Ilustración 27 : Guía IMG Estructura empresarial Sociedad GL En la guía IMG a: "Estructura de la empresa/definición/gestión financiera/definir Sociedad GL". Crearemos una sociedad llamada SES (Sap&Enterprise Solutions): Sociedad GL S&ES Tabla 4: Parametrización: Sociedad GL Nombre de la sociedad GL SAP & Enterprise Solutions 51 P á g i n a

82 División GL De nuevo desde la IMG a: "Estructura de la empresa/definición/gestión financiera/definir división". Creamos una división llamada DSES: Identificador división DSES Tabla 5: Parametrización: División Descripción División SES Divisiones y subdivisiones de personal De nuevo desde la IMG a: "Estructura de la empresa/definición/gestión recursos humanos/". Creamos las cuatro divisiones de personal que conforman nuestra sociedad SES: División de personal Texto de la división de personal LO Logística HCM HCM (Human Resources Management) MO Movilidad FI Finanzas Tabla 6: Parametrización: Divisiones de personal Cada una de las divisiones creadas tiene sus propias subdivisiones de personal. Vemos un ejemplo de cómo se definirían en el sistema para la división Logística. En este caso hay una única subdivisión que es Control de Calidad. 52 P á g i n a

83 Ilustración 28: Ejemplo parametrización: Subdivisiones de persona Para todas las demás divisiones quedaría de la siguiente manera: División Subdivisión Texto Subdivisión LO CA Control Calidad SELC Depto. Selección HCM UT Utilities APP Desarrollo Apps MO CLOU Servicios Cloud CO Depto. Costes FI VE Depto. Ventas Asignar división personal a sociedad Tabla 7: Parametrización: Subdivisiones de personal Tan importante como definir la sociedad y divisiones por separado es definir las vinculaciones entre ellas. Para esto necesitamos las asignaciones, para poner en relación las divisiones de personal con la sociedad a la que pertenecen. En la guía IMG a: "Estructura de la empresa/ Asignación/ Gestión Recursos Humanos/ Asignación de división de personal a sociedad. Vemos un ejemplo para la división logística (LO): 53 P á g i n a

84 Ilustración 29: Ejemplo de parametrización: asociación división-sociedad GL Es muy importante que la agrupación de países se identifique como 04, pues es la correspondencia con España. De la misma manera que para la división logística se hace para las otras tres divisiones. Ya hemos parametrizado la estructura empresarial de nuestra compañía SES Estructura personal Grupos y áreas de personal En la guía IMG a: "Estructura de la empresa/ Definición/ Gestión Recursos Humanos/ Grupos de personal Nuestro grupo de personal será Activos y el área de personal será Mensuales. Estas definiciones sirven para agrupar a los empleados. Los nuestros siempre serán activos, y siempre cobrarán por meses. Por este motivo elegimos estos nombres. Grupo de personal Denominación Grupo Personal 01 Activos Área de personal Denominación Área de Personal 16 Mensuales Tabla 8: Parametrización: grupos y áreas de personal 54 P á g i n a

85 De la misma forma que se deben relacionar las divisiones de personal con la sociedad de la que dependen, asignamos nuestra área de personal con nuestro grupo de personal. En la guía IMG a: "Estructura de la empresa/ Asignación/ Gestión Recursos Humanos/ Asignación de área de personal a grupo de personal Ilustración 30: Ejemplo de parametrización: Grupos y áreas de personal Ya tenemos nuestra estructura de personal. Todos nuestros empleados pertenecerán a ese grupo y a esa área de personal Estructura organizativa Plan de organización Para crear nuestro plan de organización no nos va a servir la IMG, vamos a necesitar acceder desde el menú SAP principal. Se llama SAP Easy Access. Seguimos la ruta Menú SAP/ Recursos Humanos/ Gestión de organizaciones/ Plan de organización/ Organización y ocupación/ Crear 55 P á g i n a

86 Ilustración 31: Menú SAP Easy Access Creamos las unidades organizativas que van a hacer las veces de departamentos diferenciados de nuestra empresa SES. Ilustración 32: Plan de organización SES 56 P á g i n a

87 Plan de ocupación Ahora vamos a pasar al plan de ocupación, que consiste en crear funciones, posiciones, y asignar un titular a cada una de las posiciones. Vemos un ejemplo para la división de Logística. Según lo que diseñamos previamente, su subdivisión tendrá una función y una posición llamada Consultor de Calidad. En la siguiente imagen vemos el proceso de creación: Ilustración 33: Ejemplo parametrización: crear posiciones Finalmente, cada subdivisión de personal tendrá sus posiciones asociadas, como se observa en la ilustración. Ahora vamos a aplicar una medida de contratación a un empleado para que ocupe esa posición. Se hace en la PA40 y la medida consiste en ir pasando por los infotipos que queremos rellenar: 57 P á g i n a

88 Ilustración 34: Ejemplo parametrización: medidas de personal Rellenamos los infotipos 0001, asignación organizativa, 0002, datos personales, 0006, direcciones y 0024, cualificaciones. Al acabar de ejecutar el infogrupo, en la PA30, datos de personal, veos qué aspecto tiene uno de nuestros empleados SES: Ilustración 35: Infotipos de personal SES De vuelta a nuestro plan de ocupación podemos ver en la imagen en amarillo la posición y en verde el titular de la posición que acabamos de crear: 58 P á g i n a

89 El plan de ocupación completo se observa en la siguiente imagen: 59 P á g i n a

90 60 P á g i n a

91 5.3. Análisis y diseño de la solución móvil En este apartado vamos a especificar los casos de uso de la aplicación, en función del alcance previamente definido. Después se expone un estudio de la arquitectura completa de la solución y se presentan los diagramas de secuencia para ilustrar cómo interacciona cada bloque al ejecutar cada uno de los casos de uso Casos de uso El modelo de casos de uso nos va a permitir recoger todos los requerimientos y funciones del sistema. Primero vamos a presentar un diagrama de casos de uso general, y luego una descripción detallada de cada uno de los casos. En el siguiente diagrama vemos gráficamente los casos de uso del sistema, las relaciones entre ellos y los actores que interactúan con la solución móvil. Ilustración 36: Diagrama de casos de uso 61 P á g i n a

92 A continuación vamos a analizar detalladamente cada caso de uso: Caso de uso: Descripción: Actores: 1. Visualizar datos de los empleados Al arrancar la aplicación el manager tendrá a su disposición todos los datos de todos los empleados de los que es responsable. Manager Precondiciones: El servidor dónde se encuentren los datos debe estar arrancado y operativo. Trigger: - Escenario primario: Extensiones: Descripción de los datos: 1. El manager arranca la aplicación datos: Número de empleado, Nombre, Apellidos, DNI, Lugar de procedencia, Dirección, Código postal, Población, Teléfono, Sociedad, División, Posición, Unidad Organizativa, Cualificaciones asociadas, Nivel de cada cualificación. Tabla 9: Caso de uso 1: Visualizar datos de empleados Caso de uso: Descripción: Actores: Precondiciones: Trigger: Escenario primario: 2. Buscar empleados Una vez que se listen todos los empleados, el usuario puede hacer una búsqueda por número de empleado Manager -El servidor dónde se encuentren los datos debe estar arrancado y operativo. -El empleado debe pertenecer a la sociedad del manager. El usuario debe realizar una búsqueda 1. El manager arranca la aplicación 2. El manager realiza una búsqueda por número de empleado 3. Los datos del empleado son mostrados en detalle 62 P á g i n a

93 Extensiones: Descripción de los datos: 2. a. No existe un empleado con el número buscado 1. El sistema informa de que no hay datos para ese empleado. datos: Número de empleado, Nombre, Apellidos, DNI, Lugar de procedencia, Dirección, Código postal, Población, Teléfono, Sociedad, División, Posición, Unidad Organizativa, Cualificaciones asociadas, Nivel de cada cualificación. Tabla 10: Caso de uso 2: Buscar empleados Caso de uso: Descripción: Actores: Precondiciones: Trigger: Escenario primario: Extensiones: Descripción de los datos: 3. Modificar datos personales El usuario podrá actualizar los datos personales de cualquiera de los empleados Manager -El servidor dónde se encuentren los datos debe estar arrancado y operativo. -El empleado debe pertenecer a la sociedad del manager. -El usuario debe seleccionar el empleado a modificar -El usuario debe introducir los nuevos datos del empleado 1. El manager arranca la aplicación 2. El manager selecciona el empleado a modificar 3. El manager introduce los nuevos datos 4. Los datos se actualizan en el sistema 3.a. Los datos introducidos no son válidos 1. Se muestra un mensaje de fallo en la operación datos: Número de empleado, Nombre, Apellidos, DNI, Lugar de procedencia, Dirección, Código postal, Población, Teléfono, Sociedad, División, Posición, Unidad Organizativa, Cualificaciones asociadas, Nivel de cada cualificación. Tabla 11: Caso de uso 3: Modificar datos personales 63 P á g i n a

94 Caso de uso: Descripción: Actores: Precondiciones: 4. Consultar cualificaciones Al arrancar la aplicación se listan automáticamente todas las cualificaciones con los empleados que las cumplen. Manager -El servidor dónde se encuentren las cualificaciones debe estar arrancado y operativo. Trigger: - Escenario primario: 1. El manager arranca la aplicación Extensiones: - Descripción de los datos: cualificaciones: Nombre cualificación, Nombre de empleado, Posición, Unidad Organizativa, Teléfono de contacto. Tabla 12: Caso de uso 4: Consultar cualificaciones Caso de uso: Descripción: Actores: Precondiciones: Trigger: Escenario primario: Extensiones: 5. Buscar empleados que posean una cualificación El usuario busca empleados por el nombre de la cualificación que desea satisfacer Manager -El servidor dónde se encuentren las cualificaciones debe estar arrancado y operativo. -La cualificación debe existir en el catálogo de la sociedad del manager. El usuario debe realizar una búsqueda 1. El manager arranca la aplicación 2. El manager realiza un búsqueda por nombre de cualificación 3. Se muestra en pantalla la cualificación con los empleados asociados a ella 2. a. No existe esa cualificación en el sistema 1. El sistema informa de que no hay datos. Descripción de los datos: cualificación: Nombre cualificación, Nombre de empleado, Posición, Unidad Organizativa, Teléfono de contacto. Tabla 13: Caso de uso 5: Buscar empleados que posean una cualificación 64 P á g i n a

95 Caso de uso: Descripción: Actores: 6. Consultar catálogo de cursos formativos Al arrancar la aplicación se listan automáticamente todos los cursos formativos ofrecidos y las cualificaciones asociadas a cada curso. Manager Precondiciones: - El servidor dónde se encuentren los cursos debe estar arrancado y operativo. Trigger: - Escenario primario: Extensiones: - 1. El manager arranca la aplicación Descripción de los datos: cursos: Nombre del curso, Nombre de las cualificaciones asociadas al curso. Tabla 14: Caso de uso 6: Consultar catálogo de cursos formativos Estudio arquitectura del sistema En este capítulo vamos a analizar la arquitectura del sistema completo. De esta manera podemos observar los bloques principales que forman parte del proceso y la forma de interaccionar y comunicarse entre ellos. A continuación vemos un esquema gráfico de la arquitectura de la solución: 65 P á g i n a

96 Ilustración 37: Arquitectura del sistema Diagramas de secuencia En base a los casos de uso que tenemos que implementar y la arquitectura del sistema que acabamos de ver, se presentan ahora los diagramas de secuencia de cada proceso que se ejecute en la aplicación. Este análisis nos va a servir para definir cuántas funciones RFCs necesitamos y cómo se va a configurar el Gateway y el servicio OData. 66 P á g i n a

97 Visualizar datos de empleados Ilustración 38: Diagrama secuencia 1: VISUALIZAR DATOS DE LOS EMPLEADOS En este caso no habrá ninguna request por parte del usuario desde el dispositivo móvil, directamente se requiere la colección ColEmpleados y se ejecuta el método COLEMPLEADOS_GET_ENTITYSET() en el servicio de Gateway. En este método se debe efectuar una redefinición para implementar un filtro que devuelva toda la colección, o una entrada con el empleado que hemos filtrado desde el dispositivo. En el caso de visualización de datos de empleados, no se ha pasado ningún filtro y se devuelven todos los empleados SES, invocando a la RFC Z_EMPLEADOS. 67 P á g i n a

98 Buscar empleados Ilustración 39: Diagrama de secuencia 2: BUSCAR EMPLEADOS En este caso se comienza la interacción introduciendo una búsqueda por parte del usuario en el dispositivo móvil. La búsqueda debe ser por número de empleado. En este caso, al llegar al Gateway, se ejecuta el filtro y se busca en la colección que devuelve Z_EMPLEADOS la entrada del empleado seleccionado. En la respuesta HTTP se devuelve ColEmpleados(Número=num) 68 P á g i n a

99 Modificar datos personales Ilustración 40: Diagrama de secuencia 3: MODIFICAR DATOS PERSONALES Para llevar a cabo este caso de uso, el usuario rellena un formulario de actualización de datos personales del empleado seleccionado. En el Gateway se busca el método COLEMPLEADOS_UPDATE_ENTITY(), que se debe redefinir. En él, se llama a la RFC Z_UPDATE_EE que también deberemos implementar. Esta RFC recibe los nuevos datos del empleado y va recorriendo los infotipos a los que pertenece cada dato y haciendo las actualizaciones. Al finalizar, se recarga la aplicación para mostrar las actualizaciones. 69 P á g i n a

100 Consultar cualificaciones Ilustración 41: Diagrama de secuencia 4: CONSULTAR CUALIFICACIONES Al comienzo no hay interacción con el usuario, se requiere la colección ColCualificaciones por lo que se busca ejecuta el método COLCUALIFICACIONES_GET_ENTITYSET() en el servicio de gateway. Al igual que pasaba con la colección de empleados, debemos redefinir este método para implementar un filtro que devuelva todas las cualificaciones y los empleados que las posean, o solo la cualificación que se desee buscar. En este caso, no hay parámetro de filtro y se devuelve la tabla completa. En la respuesta HTTP, la colección ColCualificaciones. Cabe mencionar que la RFC Z_CUALIFICACIONES descarga el catálogo de cualificaciones y enlaza cada cualificación con todos los empleados que la poseen. 70 P á g i n a

101 Buscar empleados que posean una cualificación Ilustración 42: Diagrama de secuencia 5: BUSCAR EMPLEADOS QUE POSEAN UNA CUALIFICACIÓN Se comienza la interacción introduciendo una búsqueda por parte del usuario en el dispositivo móvil. La búsqueda debe ser por nombre de cualificación. En este caso, al llegar al Gateway, se ejecuta el filtro y se busca en la colección que devuelve Z_CUALIFICACIONES la entrada de la cualificación seleccionada. En la respuesta HTTP se devuelve ColCualificaciones(Nombre=CualNom) 71 P á g i n a

102 Consultar catálogo de cursos formativos Ilustración 43: Diagrama de secuencia 6: CONSULTAR CATÁLOGO DE CURSOS FORMATIVOS En este caso no es necesario redefinir el método COLCURSOS_GET_ENTITYSET() en el Gateway, porque no se va a interaccionar desde la aplicación. Será necesario únicamente definir un mapeo de las propiedades entre el servicio de Gateway y los parámetros export de la RFC Z_CURSOS. 72 P á g i n a

103 5.4. Programación de las RFCs (Remote Function Call) Como se observa en el diagrama de la arquitectura del sistema, para acceder a los datos del R/3, necesitamos las funciones llamadas RFCs programadas en ABAP. Estas funciones interaccionan con el sistema recogiendo los datos que necesitemos y haciéndolos accesibles desde fuera del sistema. A continuación se muestra la manera de implementar estas funciones ABAP: El primer paso es crearse un grupo de funciones en la transacción SE80. Este grupo de funciones será el que englobe las RFCs de todo nuestro proyecto. El nombre identificador es Z_RH_MGC. En este grupo de funciones es dónde vamos a ir añadiendo los módulos remotos que nos harán falta para cumplir los requisitos de este proyecto. Al finalizar, el grupo de funciones tiene la siguiente apariencia: Ilustración 44: Grupo de funciones Z_RH_MGC. 73 P á g i n a

104 En los siguientes apartados se observa brevemente cómo se han implementado cada uno de los módulos Z_INFOEMPLEADOS La primera RFC (módulo de función en remoto) que nos vamos a crear es la que cumple el caso de uso Visualizar datos de empleados de SES. Lo llamamos Z_INFOEMPLEADOS. Lo que se pretende que haga esta función es recibir un número de empleado (como import) y devolver una estructura (tabla de una única entrada de datos o línea) con los campos de datos que pertenecen a ese empleado (como export). Los campos de datos que deseamos que devuelva la función se encuentran en diversos infotipos. Es decir, queremos recuperar únicamente ciertos campos de ciertos infotipos. En la fase de análisis se consideró que los infotipos interesantes eran el 0001 (asignación organizativa), 0002 (datos personales), 0006 (direcciones), 0024 (cualificaciones). Como no existe una estructura estándar que mezcle campos de infotipos diferentes debemos de crearla nosotros mismos. En la transacción SE11 se crea la estructura y añadimos mano los campos que queramos. Esta estructura se llamará ZHR_INFTY. En la siguiente imagen vemos cómo quedaría: 74 P á g i n a

105 la función: Ilustración 45: Estructura ZHR_INFTY Una vez creada la estructura volvemos a la RFC y estipulamos los parámetros de Parámetros Los exports serán la estructura recién creada y la variable RC, que corresponde a SY-SUBRC. Esta es una variable del sistema que devuelve el valor 0 si todo ha ido bien durante la ejecución. Ilustración 46: Exports Z_INFOEMPLEADOS 75 P á g i n a

106 Los imports serán el número de empleado y las fechas de comienzo y de fin. Ilustración 47: Imports Z_INFOEMPLEADOS Para leer los infotipos existe un módulo estándar que provee el sistema SAP y que se llama HR_READ_INFOTYPE. Llamaremos a este módulo para leer los infotipos 0001, 0002, El infotipo de cualificaciones, el 0024, es especial y la función estándar que lo lee se llama RHPP_Q_PROFILE_READ. Ilustración 48: Diagrama de bloques Z_INFOEMPLEADOS 76 P á g i n a

107 Código fuente Exponemos aquí partes del código ABAP de la función a modo de ejemplo: Llamada a la función HR_READ_INFOTYPE para el infotipo 1 *LECTURA it asignación organizativa data: ls_p0001 type p0001, lt_pa0001 type table of pa0001. call function 'HR_READ_INFOTYPE' exporting * TCLAS = 'A' pernr = numero_empl infty = '0001' begda = begda endda = endda * BYPASS_BUFFER = ' ' * LEGACY_MODE = ' ' importing subrc = rc tables infty_tab = lt_pa0001. * EXCEPTIONS * INFTY_NOT_FOUND =. * OTHERS = 2. Se recorre la tabla que nos ha devuelto la función (lt_pa0001) y nos quedamos con los campos que queremos, asignándoselos a nuestra estructura (tabla1) que vamos a exportar: 77 P á g i n a

108 read table lt_pa0001 into ls_p0001 index 1. "leemos de info0001 lv_found = 'X'. tabla1-num = ls_p0001-pernr. tabla1-sociedad = ls_p0001-bukrs. select single name1 from t500p into tabla1-division where persa = ls_p0001-werks. select single orgtx from t527x into tabla1-uniorg where sprsl = 'S' and orgeh = ls_p0001-orgeh. select single mc_stext from hrp1000 into tabla1-posicion where plvar = '01' and otype = 'S' and objid = ls_p0001-plans. Se adjunta un ejemplo de test del módulo Z_INFOEMPLEADOS. Se pasa un número de empleado ( en el ejemplo), y se devuelve una tabla con los datos que hemos seleccionado de entre los infotipos. Ilustración 49: Test Prueba Z_INFOEMPLEADOS 78 P á g i n a

109 Z_EMPLEADOS Esta RFC complementa a la anterior en la consecución del caso de uso Visualización de empleados de SES. Su objetivo es llamar a Z_INFOEMPLEADOS e ir pasándole progresivamente los números de empleados de la sociedad SES. Esta función es necesaria pues Z_INFOEMPLEADOS no devuelve nada si no le pasamos un número. Por este motivo Z_EMPLEADOS no tiene imports y el export es una tabla del tipo ZTHR_INFTY. Debe ser una tabla y no una estructura pues habrá varias entradas (filas). Es por esto que se debe crear una tabla ZTHR_INFTY a partir de la estructura que teníamos ZHR_INFTY, que se especificará como tipo de línea. Ilustración 50: Tabla ZTHR_INFTY figura: El diagrama de bloques de esta función es el que se observa en la siguiente 79 P á g i n a

110 Ilustración 51: Diagrama de bloques Z_EMPLEADOS Mostramos una parte del código fuente de esta función. Iteramos los empleados del 0 al 150 para que el tiempo de ejecución no se dispare, llamamos a la función y añadimos la entrada devuelta a la tabla (tabla1) que vamos a exportar (con el comando append). Se observa que la entrada solo es añadida si la sociedad a la que pertenece el empleado es SES. lv_cont = '0'. while lv_cont < '150'. call function 'Z_INFOEMPLEADOS' exporting numero_empl = lv_cont * BEGDA = ' ' * ENDDA = ' ' importing tabla1 = ls_empleado * RC = exceptions infotype_not_found = 1 others = 2. lv_cont = lv_cont + 1. if sy-subrc = 0 and ls_empleado-sociedad eq 'SES'. append ls_empleado to tabla1. endif. endwhile. 80 P á g i n a

111 Como ejemplo de ejecución vemos que la RFC devuelve todos los empleados que pertenecen a la sociedad SES. Ilustración 52: Test Prueba Z_EMPLEADOS Z_UPDATE_EE Esta RFC nos permite cumplir el caso de uso Modificar datos personales del empleado. El objetivo es pasarle una estructura del tipo ZHR_INFTY y que la función se encargue de modificar los datos que trae esa estructura. Se hará en base al número de empleado (parámetro que no se podrá modificar). Si los campos vienen vacíos no se actualizan. Esta función tendrá por tanto un import y ningún export. Se va a hacer uso de la función estándar 'HR_INFOTYPE_OPERATION', que ejecuta la acción requerida sobre el infotipo seleccionado. El paso previo a realizar la operación sobre el infotipo, es bloquear el objeto, en este caso el empleado, que se va a actualizar, para asegurarnos que no se accede a él durante la modificación. El diagrama de bloques de esta RFC se ve en la siguiente figura: 81 P á g i n a

112 Ilustración 53: Diagrama de bloques Z_UPDATE_EE En el siguiente ejemplo de código vemos cómo se llama a esta función en el código fuente. Se está modificando el infotipo 0002 (datos personales). Lo primero es descargar en una tabla todos los campos del infotipo Todo el contenido de los infotipos se guarda en las tablas pa + número de infotipo. En este caso en la pa0002 : * INFOTIPO 2 select single * from pa0002 into lt_2 where pernr = tabla_empl-num. move-corresponding lt_2 to ls_2. ls_2-infty = '0002'. Llamada a la función que ejecute la operación. Se le está pasando a la función el infotipo, el número de personal del empleado a modificar, las fechas, y los dos 82 P á g i n a

113 parámetros más importantes: el record (estructura con los datos a modificar) y el código de operación MOD (modificar). call function 'HR_INFOTYPE_OPERATION' exporting infty = '0002' number = ls_2-pernr "employeenumber validityend = ls_2-endda validitybegin = ls_2-begda lockindicator = '' record = ls_2 recordnumber = 000 operation = 'MOD' dialog_mode = '1' importing return = lv_ret key = lv_key exceptions others = 1. De esta manera se van modificando los datos en los infotipos del sistema. Se llamará sucesivamente a los demás infotipos pasándoles los nuevos datos Z_CUALIFICACIONES Esta función cumple con el caso de uso Consultar cualificaciones. El objetivo es obtener el catálogo de cualificaciones completo de la sociedad SES y saber qué empleados cumplen qué cualificaciones. De esta manera se cumple también el caso de uso Buscar empleados por cualificación. Para ello vamos a utilizar la función estándar del sistema HRTM_GET_QUALI_CATALOG_WD_UI, que nos devuelve el catálogo del sistema; y PAD_EMPLOYEE_BY_QUALI_GET, a la que se le pasa un id de cualificación y devuelve una lista con los empleados que tienen esa cualificación en su infotipo P á g i n a

114 Esta RFC no tendrá imports y devolverá como export una tabla con la cualificación del catálogo y los datos de los empleados que cumplen la cualificación. Para ello debemos de crear otro tipo estructura con los campos que nos interesan. Esta estructura se llama ZHR_CUAL y los campos se observan en la siguiente figura: Ilustración 54: Estructura ZHR_CUAL Asimismo, debemos crear también su tabla asociada ZTHR_CUAL, indicando como tipo de línea el de la estructura ZHR_CUAL: Ilustración 55: Tabla ZTHR_CUAL 84 P á g i n a

115 El diagrama de bloques se observa en la siguiente figura: Ilustración 56: Diagrama de bloques Z_CUALIFICACIONES En el código fuente primero se llama a la función que devuelve el catálogo de cualificaciones (lt_cual): call function 'HRTM_GET_QUALI_CATALOG_WD_UI' * EXPORTING * DEPTH = '0' importing * T_RETURN = t_qualificationcatalog = lt_cual. 85 P á g i n a

116 Después se itera sobre la tabla que nos devuelve y se llama a la otra función estándar pasándole cada una de las cualificaciones. Nos devuelve otra tabla (lt_aux) con el número de cada empleado que la tiene: loop at lt_cual into ls_cual where otype = 'Q' call function 'PAD_EMPLOYEE_BY_QUALI_GET' exporting iv_qualification_id = ls_cual-objid * IV_QUALIFICATION_LEVEL = '0000' * IV_ORGANIZATIONAL_UNIT = * IV_JOB = * IV_CONSIDER_HIERARCHY = FALSE * IV_MAX_NUMBER_QUERY_HITS = * IV_QUERY_HIT_NUMBER_UNLIMITED = TRUE * KEYDATE = SY-DATUM * STARTDATE = * ENDDATE = * NO_MAX_HITS = importing * EV_MAX_QUERY_HITS_EXCEEDED = * EV_NUMBER_QUERY_HITS = ev_employees = lt_aux tables et_messages = r_return. endloop. Ahora en la RFC se debe iterar sobre la tabla lt_aux y llamar a la función Z_INFOEMPLEADOS pasándole cada uno de los IDs. Esto se hace para tener la información completa de cada empleado y no sólo el número. Como último paso se recogen de la estructura devuelta (ls_empl_aux) lo campos deseados, y se adjuntan a la tabla_cual que se va a exportar. 86 P á g i n a

117 loop at lt_aux into ls_aux where iv_ext_person_id > 100 and iv_ext_person_id < 150. lv_var = ls_aux-iv_ext_person_id. call function 'Z_INFOEMPLEADOS' exporting numero_empl = lv_var * BEGDA = ' ' * ENDDA = ' ' importing tabla1 = ls_empl_aux * RC = * EXCEPTIONS * INFOTYPE_NOT_FOUND = 1 * OTHERS = 2. ls_empl-num_empl = ls_empl_aux-num. ls_empl-nombre_empl = ls_empl_aux-nombre. ls_empl-ap1_empl = ls_empl_aux-apellido1. ls_empl-ap2_empl = ls_empl_aux-apellido2. ls_empl-pos_empl = ls_empl_aux-posicion. ls_empl-uniorg_empl = ls_empl_aux-uniorg. ls_empl-tfn_empl = ls_empl_aux-telefono. append ls_empl to tabla_cual. endloop Z_CURSOS Esta función cumple con el caso de uso Consultar catálogo de cursos formativos. El objetivo es obtener el catálogo de cursos disponibles para realizar por cualquier empleado, así como el conjunto de cualificaciones que se pueden obtener tras la realización del curso. Para ello vamos a recorrer las tablas HRP1000 y HRP1001 que contienen la información detallada de cada objeto y el conjunto de objetos asociados, respectivamente. 87 P á g i n a

118 Esta RFC no tendrá imports y devolverá como export una tabla con el catálogo de cursos y el conjunto de cualificaciones asociada a cada curso nombre e identificador. Para ello debemos crear otro tipo estructura con los campos que nos interesan. Esta estructura se llama ZHR_CURSO y los campos se observan en la siguiente ilustración: Ilustración 57: Estructura ZHR_CURSO De la misma manera se crea la tabla asociada ZTHR_CURSO Ilustración 58: Tabla ZTHR_CURSO Lo vemos gráficamente en un diagrama de bloques en la siguiente figura: 88 P á g i n a

119 Ilustración 59: Diagrama de bloques Z_CURSOS Como hemos dicho, el código itera sobre las tablas HRP1000 y HRP1001 y almacena los valores deseados en nuestra tabla de export (tablacursos). select * from hrp1000 into table lt_0 where plvar = '01' and otype = 'B'. loop at lt_0 into ls_0. est_aux-nomcurso = ls_0-stext. est_aux-idcurso = ls_0-objid. select * from hrp1001 into table lt_1 where objid = ls_0- objid and otype = 'B'. loop at lt_1 into ls_1. est_aux-idcual = ls_1-sobid. select single * from hrp1000 into ls_2 where plvar = '01' and otype = 'Q' and objid = ls_1-sobid. est_aux-nomcual = ls_2-stext. append est_aux to tablacursos. endloop. endloop. 89 P á g i n a

120 5.5. Servicio OData en el Sap NetWeaver Gateway Queremos construir un servicio OData que nos exporte los datos desde el backend. Para construir un servicio de Gateway se necesita seguir una serie de pasos en el Sap NetWeaver Builder Service, al que se accede a través de la transacción SEGW. EL primer paso es crear un modelo de datos Modelo de datos Primero debemos crear un proyecto y un modelo de datos que albergará todos los servicios que necesitemos a lo largo del proyecto. El proyecto se llamará Z_SAPHCM. Ilustración 60: Modelo de datos Z_SAPHCM Para crear el modelo de datos se deben definir los Entity Types y los Entity Sets. Entity Types ya sabemos que son una estructura de datos a la que el servicio podrá acceder y que las vamos a importar a través de las RFCs que tenemos definidas en el sistema. El primer entity que importamos es la RFC llamada Z_INFOEMPLEADOS, el objeto que define el entity se llamará Z_Info y tendrá las propiedades de la tabla que exporta la función. Segundo entity será Z_Cual, que se obtiene importando la RFC Z_CUALIFICACIONES y el último es Z_Curso importando Z_CURSOS. 90 P á g i n a

121 Ilustración 61: Entity Types: ZInfo y ZCual Los entity sets recordamos que son las colecciones que se relacionan con los entity types. Nuestros entity set serán simplemente colecciones: de empleados, de cualificaciones y de cursos. Los llamamos ColEmpleados, ColCualificaciones y ColCursos. servicio. Ilustración 62: Entity Sets Una vez que el modelo de datos está definido se deben generar los objetos del 91 P á g i n a

122 Ilustración 63: Generación de objetos Los objetos generados son ZCL_Z_SAPHCM_MPC y ZCL_Z_SAPHCM_DPC y sus versiones extendidas, donde se redefinirán los métodos que se han generado en las clases. Ilustración 64: Objetos generados Por cada colección definida se generan unos métodos automáticamente. Estos métodos son los que se busca ejecutar cuando se quiere realizar alguna acción sobre cualquiera de las colecciones. En algunas ocasiones, bastará con mapear las propiedades de los entitys, con las de los parámetros de las RFCs importadas. Sin embargo, si se quiere realizar alguna operación desde fuera, se debe redefinir el método adecuado. A continuación vemos un ejemplo de los métodos que se han generado automáticamente para la colección ColEmpleados: 92 P á g i n a

123 Ilustración 65: Métodos autogenerados Redefinición de métodos Una vez que se ha definido la estructura y generado los objetos se deben redefinir los métodos necesarios para obtener las colecciones de datos asociados a los entity. La definición de estos métodos se realiza en la transacción SE80, accediendo a la Class/Interface ZCL_Z_SAPHCM_DPC_EXT. Seleccionamos los métodos que vamos a redefinir: Ilustración 66: Métodos redefinidos 93 P á g i n a

124 COLEMPLEADOS_GET_ENTITYSET El método COLEMPLEADOS_GET_ENTITYSET debemos redefinirlo para implementar un filtro por número de empleado. De manera que cuando se quiera buscar un empleado desde la aplicación, esté soportado por la lógica del servicio de datos. Este filtro se efectuará por la propiedad Num. Se deben definir rangos de opciones y la selección de filtro adecuada: data: lt_empleados type zhr_infty. data: li_empleados type zhr_infty. data: li_empleado type prelp-pernr. data: lt_range_empleado type range of prelp-pernr, ls_range_empleado like line of lt_range_empleado, ls_filter_select_options type /iwbep/s_mgw_select_option, ls_mgw_select_options type /iwbep/s_mgw_select_option, ls_mgw_range_options type /iwbep/s_cod_select_option. field-symbols <lf_empleados> type zhr_infty. field-symbols <lf_entityset> type zcl_z_saphcm_mpc=>ts_zinfo. loop at it_filter_select_options into ls_filter_select_options. loop at ls_filter_select_options-select_options into ls_mgw_range_options. translate ls_filter_select_options-property to upper case. case ls_filter_select_options-property. when 'NUM'. li_empleado = ls_mgw_range_options-low. endcase. endloop. endloop. 94 P á g i n a

125 Después se llama a nuestra RFC Z_EMPLEADOS para descargarnos todos nuestros empleados: DATA: ti_empleados TYPE TABLE OF zhr_infty. CALL FUNCTION 'Z_EMPLEADOS' IMPORTING tabla1 = ti_empleados * RC = * EXCEPTIONS * EMPLEADO_NOT_FOUND = 1 * OTHERS = 2. IF sy-subrc <> 0. * Implement suitable error handling here ENDIF. Y por último se efectúa el bucle de filtrado. Cuando el número d empleado coincida con el criterio de búsqueda, realiza el append de ese único empleado, si no se ha realizado búsqueda, se hace el append de toda la tabla, es decir, todos los empleados: LOOP AT ti_empleados ASSIGNING <lf_empleados>. IF li_empleado IS NOT INITIAL. IF <lf_empleados>-num = li_empleado. APPEND INITIAL LINE TO et_entityset ASSIGNING <lf_entityset>. MOVE-CORRESPONDING <lf_empleados> TO <lf_entityset>. endif. ELSE. APPEND INITIAL LINE TO et_entityset ASSIGNING <lf_entityset>. MOVE-CORRESPONDING <lf_empleados> TO <lf_entityset>. ENDIF. ENDLOOP. 95 P á g i n a

126 COLEMPLEADOS_UPDATE_ENTITY El método COLEMPLEADOS_UPDATE_ENTITY se activa cuando se lanza una petición HTTP utilizando el método PUT, necesario para actualizar los datos. El código consiste en leer los datos de entrada que se mandan desde la petición. El formato de los datos debe ser una estructura tipo ZHR_INFTY, el mismo tipo del entity type ZInfo. data: ls_so_pro type zcl_z_saphcm_mpc=>ts_zinfo. io_data_provider->read_entry_data( importing es_data = ls_so_pro ). data: tabla_empl type zhr_infty. Los datos leídos (ls_so_pro), se pasan a la RFC Z_UPDATE_EE que se encargará de actualizar los infotipos en el sistema, sin devolver nada. Anteriormente se debe validar que se han recibido datos en la petición PUT. if ls_so_pro is not initial. call function 'Z_UPDATE_EE' exporting tabla_empl = ls_so_pro * importing * tabla =. endif. 96 P á g i n a

127 COLCUALIFICACIONES_GET_ENTITYSET Del mismo modo, en el método COLCUALIFICACIONES_GET_ENTITYSET se implementa el filtro por nombre de cualificación, propiedad CualNombre. En este punto ya se tiene el modelo de datos al que se puede acceder vía HTTP. En el navegador, podemos ver los datos que devuelven cada una de nuestras colecciones utilizando la URL del servicio. Vemos un ejemplo para la colección ColEmpleados. Ilustración 67: Ejemplo de petición HTTP al modelo OData 97 P á g i n a

128 5.6. Programación de la solución móvil en SAPUI5 Para programar la apariencia de nuestra aplicación ya hemos comentado que vamos a utilizar el interfaz de usuario de SAP Fiori. Este tipo de soluciones móviles se desarrollan utilizando el toolkit de desarrollo SAPUI5. El runtime de SAPUI5 es una librería del lado del cliente basada en HTML5 con una gran variedad de componentes que permite desarrollar aplicaciones móviles y de escritorio. Basándonos en el toolkit de desarrollo de Sap Fiori y en las buenas prácticas de desarrollo en SAPUI5, como el MVC, nuestro proyecto tendrá la siguiente apariencia: Ilustración 68: Proyecto de la solución móvil final Vemos que el proyecto está formado por unas carpetas de recursos donde están instaladas las librerías de SAP Fiori, de SAPUI5 y de OData Development; y una carpeta principal llamada Web Content, donde los archivos más importantes son el 98 P á g i n a

129 index.html y otra carpeta llamada bp_sapui5_fiori, que contiene los archivos con las vistas y controladores implementados index.html La etiqueta de bootstrapt: <script src="resources/sap-ui-core.js" id="sap-ui-bootstrap" data-sap-ui-libs="sap.ui.commons,sap.ui.layout,sap.ui.table, sap.m,sap.ui.core,sap.makit,sap.ca.ui" data-sap-ui-theme="sap_bluecrystal" data-sap-ui-xx-bindingsyntax="complex" data-sap-ui-resourceroots='{"sapfiori_mgc": "./"}'> </script> Al index.html hay que añadirle varios scripts con los recursos a utilizar durante todo el proyecto y también la localización de un fichero de configuración Application.js: <script> sap.ui.localresources("bp_sapui5_fiori"); sap.ui.localresources("util"); sap.ui.localresources("css"); </script> jquery.sap.registermodulepath('application', 'Application'); jquery.sap.require("application"); var oapp = new Application({root : "content"}); <body class="sapuibody" role="application"> <div id="content"> </body> </div> 99 P á g i n a

130 Application.js Application.js es un fichero que tiene una triple misión: inicializa la aplicación, lanza la primera pantalla y establece la conexión con el modelo de datos del sistema. Tiene dos métodos, init() y main(): init : function () { }); var m; var sserviceurl = " m= new sap.ui.model.odata.odatamodel(sserviceurl, true, "user","password"); sap.ui.getcore().setmodel(m); m.attachrequestcompleted(function () { sap.ui.getcore().geteventbus().publish("app", "DataLoaded"); } main : function () { // create app view and put to html root element var root = this.getroot(); sap.ui.xmlview("app", "bp_sapui5_fiori.mainview").placeat(root); } Si ahora desplegamos la carpeta bp_sapui5_fiori, podemos encontrar todas nuestras vistas y controladores. Recordamos que en las vistas es dónde se realiza la presentación y en los controladores es dónde se encuentra la lógica de la vista asociada. En la siguiente imagen podemos ver el conjunto de todas nuestras vistas: 100 P á g i n a

131 Ilustración 69: Carpeta Web Content de la solución móvil final MainView La primera vista que se muestra en la aplicación es la MainView. En ella se van a desplegar los iconos de acceso rápido a la funcionalidad de la aplicación. En la vista MainView.view.xml se implementa de la siguiente manera: 101 P á g i n a

132 <content> <TileContainer> <tiles> <StandardTile icon="sap-icon://group" number="1" title="datos de empleados" info="actualizaciones" press = "handlenavigation" class ="customtile"/> <StandardTile icon="sap-icon://table-chart" number="2" title="cualificaciones" info="listado" press = "handlenavigation" class ="customtile"/> <StandardTile icon="sap-icon://hint" number="3 title="cursos formativos" info="desarrollo de personal" press = "handlenavigation" class ="customtile"/> </tiles> </TileContainer> </content> En la vista hemos especificado que el método a ejecutar cuando se presionan los iconos es handlenavigation. La implementación de este método se encuentra en el MainView.controler.js 102 P á g i n a

133 sap.ui.controller( bp_sapui5_fiori.mainview, { handlenavigation: function(e) { switch(e.osource.mproperties.title) { case "Datos de empleados": app.to(appempleados); break; case "Cualificaciones": app.to(cualificacionesview); break; case "Cursos formativos": app.to(cursosview); break; }; }, } Vemos que la vista que se abre al pulsar el icono de Employee Data es appempleados. Aquí hemos definido lo que se llama una página dividida (SplitApp). Este control sap.m.splitapp define dos páginas (máster y detail) con la navegación de una a la otra AppEmpleados Esta vista AppEmpleados.view.js es una vista javascript. El formato cambia levemente. La implementación se hace por javascript y no por xml, a través del método createcontent(). 103 P á g i n a

134 sap.ui.jsview( bp_sapui5_fiori.appempleados, { createcontent : function(ocontroller) { this.setdisplayblock(true); this.app = new sap.m.splitapp(); // load the master page var master = sap.ui.xmlview("employeedataview", "bp_sapui5_fiori.employeedataview"); this.app.addmasterpage(master, true); // load the detail page var detail = sap.ui.xmlview("detailemployeedata", "bp_sapui5_fiori.detailemployeedata"); this.app.adddetailpage(detail, false); }; }, return this.app; Se observa en el código que la página máster se llama EmployeeDataView y el detail asociado es la página DetailEmployeeData: A continuación se van a exponer ejemplos de cómo se efectúa el data binding en las vistas EmployeeDataView (máster) y DetailEmployeeData (detail) EmployeeDataView En el contenido de la vista XML se referencia como ítem la colección que se quiere presentar y cada uno de los atributos del modelo de datos. 104 P á g i n a

135 <List id="list" items="{/colempleados}" mode="{device>/listmode}" select="handlelistselect" growing="true" growingscrolltoload="true"> <ObjectListItem id="main_list_item" type="{device>/listitemtype}" press="handlelistitempress" title="{nombre}" number="{num}" > <attributes> <ObjectAttribute text="{apellido1}" /> <ObjectAttribute text="{apellido2}" /> </attributes> </ObjectListItem> </List> También se implementa la barra de búsqueda: <Bar id="searchbar"> <contentleft> <SearchField id="searchfield" showrefreshbutton="{device>/isnotouch}" placeholder="search" search="handlesearch" tooltip="search for empleados" width="100%"> </SearchField> </contentleft> </Bar> En el controller, se implementarán los métodos a los que se llama desde la vista. El más importante es el handlesearch, que ejecutará la búsqueda de empleado: 105 P á g i n a

136 //BUSQUEDA handlesearch: function() { var filter; var olist = this.getview().byid("list"); var binding = olist.getbinding("items"); var searchstring = this.getview().byid("searchfield").getvalue(); if (searchstring && searchstring.length > 0) { filter = new sap.ui.model.filter("num", sap.ui.model.filteroperator.contains, searchstring); binding.filter(filter); }, }else{ } binding.filter(); Otros métodos implementados en el controller del master son los que hacen la navegación de los datos del máster al detail. handlelistitempress : function (evt) { this._showdetail(evt.getsource()); }, handlelistselect : function (evt) { this._showdetail(evt.getparameter("listitem")); }, _showdetail : function (item) { // navigate to detail page sap.ui.getcore().geteventbus().publish("nav", "to", { id : "DetailEmployeeData" }); }, // tell detail to update sap.ui.getcore().geteventbus().publish("app", "RefreshDetail", { context : item.getbindingcontext() }); 106 P á g i n a

137 DetailEmployeeData La vista del detalle está dividida en tres partes, la superior, que contiene la misma información que la página de máster; los iconos de mitad de vista, que permiten observar separadamente la información agrupada por contenido (datos personales, asignación organizativa y cualificaciones individuales); y el despliegue de dicha información. Para ello se usan los controles sap.m.objectheader, sap.m.icontabbar y sap.m.icontabfilter. En la vista DetailEmployeeData.view.xml observamos la codificación: <ObjectHeader id="detailobjectheader" title="{nombre}" number="{num}" > <attributes> <ObjectAttribute text="{apellido1}" /> <ObjectAttribute text="{apellido2}" /> </attributes> </ObjectHeader> <IconTabBar expanded="{device>/isnophone}" select="handletabselect" > <items> <IconTabFilter key="datos" icon="sap-icon://employee-lookup"/> <IconTabFilter key="info" icon="sap-icon://org-chart"/> <IconTabFilter key="notes" icon="sap-icon://notes"/> </items> </IconTabBar> 107 P á g i n a

138 Vemos a modo de ejemplo la implementación de uno de los iconos, el de asignación organizativa. Dentro del sap.m.icontabfilter, se implementa un formulario. <IconTabFilter key="info" icon="sap-icon://org-chart"> <form:simpleform id="form2" minwidth="1024" maxcontainercols="2" > <core:title text="asignación Organizativa" /> <Label text="sociedad"/> <Text text="{sociedad}"/> <Label text="división"/> <Text text="{division}"/> <Label text="unidad Organizativa"/> <Text text="{uniorg}"/> <Label text="posición"/> <Text text="{posicion}"/> </form:simpleform> </IconTabFilter> En la parte inferior de la página de detail, se va a implementar un botón de actualización de datos personales. Para ello, se utiliza el control sap.m.button en el pie de página. <footer> <Bar> </Bar> </footer> <contentright> <Button id="editbutton" text="editar datos" press="edit"> </Button> </contentright> 108 P á g i n a

139 De la misma manera en el controller DetailEmployeeData.controller.js, se definen los métodos que rigen la lógica de esta vista. Los más importantes son el init(), que recoge los datos de navegación del máster (para que el empleado seleccionado en el máster, sea el que aparece en el detail) y el edit(), que lanza la actualización de los datos. sap.ui.controller( bp_sapui5_fiori.detailemployeedata,{ oninit: function() { var bus = sap.ui.getcore().geteventbus(); bus.subscribe("app", "RefreshDetail", this._refresh, this); }, _refresh : function (channelid, eventid, data) { if (data && data.context) { // set context of selected master object this.getview().setbindingcontext(data.context); var context = this.getview().getbindingcontext(); var omodel = new sap.ui.model.json.jsonmodel({ actionsenabled : context &&!!context.getobject() }); this.getview().setmodel(omodel,"cfg"); }; }, // scroll to top of page this.getview().byid("page").scrollto(0); } El método edit() despliega un formulario con cajas de texto para rellenar con los nuevos datos del empleado. Para ello, se ejecuta una petición HTTP de read para el empleado seleccionado, (esto es para obtener su información, y que al desplegar el formulario las cajas de texto aparezcan rellenos con la información actual). Una vez actualizadas las cajas de texto y recogidos los nuevos datos, se ejecuta una petición 109 P á g i n a

140 HTTP con el método PUT. Es importante enviar todos los campos en la solicitud y no solo los campos a modificar. También se debe enviar un token X-CSRF por seguridad. edit : function(){ ServiceURL = " var context = this.getview().getbindingcontext(); var emplselect=context.getproperty("num"); OData.read(ServiceURL + "/ColEmpleados(Num='"+ emplselect +"')", function(response) { var osubdialog = new sap.ui.commons.dialog( { title: "Actualizar datos", content : [ olayout = new sap.ui.commons.layout.matrixlayout({ columns: 2, width: "100%" }), //NUM otf = new sap.ui.commons.textfield("templid", { tooltip: 'Numero personal', editable: false, value: response.num, width: '200px', required: true, }), olabel = new sap.ui.commons.label( "lemplid",{ text: 'Numero personal', labelfor: otf, }), olayout.createrow(olabel,otf); [ resto de campos ] A continuación viene la implementación del botón Update, cuando se pulsa, se recogen los valores de los campos en variables auxiliares: 110 P á g i n a

141 osubdialog.addbutton(new sap.ui.commons.button({text: "Update", press:function() { var emplnombre_var = sap.ui.getcore().getcontrol("templnombre").getvalue(); })); } [ resto de campos ] Para obtener el token de seguridad, primero se debe hacer una petición GET a cualquiera de los empleados, para luego capturar el token devuelto y adjuntarlo a la petición PUT posterior. //REQUEST GET OData.request ({ requesturi: " method: "GET", headers: { "X-Requested-With": "XMLHttpRequest", "Content-Type": "application/atom+xml; type=entry; charset=utf-8", "DataServiceVersion": "2.0", "X-CSRF-Token":"Fetch" } }, function (data, response) { var header_xcsrf_token = response.headers['x-csrf-token']; }; Ahora se realiza la petición PUT de actualización sobre el empleado que se seleccionó y pasándole los datos nuevos de insert: 111 P á g i n a

142 //REQUEST PUT OData.request ({ requesturi: " ('" + emplselect + "')", method: "PUT", headers: { "X-Requested-With": "XMLHttpRequest", "Content-Type": "application/atom+xml;type=entry;charset=utf-8", "DataServiceVersion": "2.0", "Accept": "application/atom+xml,application/atomsvc+xml,application/xml", X-CSRF-Token": header_xcsrf_token, }, data: { Num: emplselect, Nombre: emplnombre_var, Apellido1: emplapellido1_var, }); } [ resto de campos ] CualificacionesView La vista de cualificaciones hace uso de los controles sap.m.table, sap.m.column y sap.m.columnlistitem para desplegar la tabla con las cualificaciones y sus empleados asociados. Estos controles funcionan de tal manera que cada Column, tiene un ColumnListItem asociado. El CualificacionesView.view.xml es un archivo XML. Vemos cómo se define la tabla. 112 P á g i n a

143 <Table id="list" headertext="listado de cualificaciones" items="{/colcualificaciones}"> <columns> <Column halign="center" mergeduplicates="true"> <header> <Label text="cualificación" /> </header> </Column> <Column halign="center" > <header> <Label text="empleado" /> </header> </Column> <Column halign="center" > <header> <Label text="función" /> </header> </Column> <Column halign="center" > <header> <Label text="tfn contacto" /> </header> </Column> </columns> <ColumnListItem> <Text text="{cualnombre}"/> <Text text="{ap1empl} {Ap2Empl}, {NombreEmpl}"/> <Text text="{posempl}, {UniorgEmpl}"/> <Text text="{tfnempl}"/> </ColumnListItem> </Table> Esta vista CualificacionesView también tiene una barra de búsqueda y un método handlesearch en su controlador. La implementación será igual que la realizada en la vista EmployeeDataView. 113 P á g i n a

144 CursosView Esta última vista es también un archivo XML y tendrá implementada una tabla con las propiedades de la colección ColCursos, de nuestro modelo de datos. <Table id="list" items="{/colcursos}"> <columns> <Column halign="center" mergeduplicates="true"> <header> <Label text="curso" /> </header> </Column> <Column halign="center" > <header> <Label text=" " /> </header> </Column> </columns> <ColumnListItem> <Text text="{nomcurso}"/> <Text text="{nomcual}"/> </ColumnListItem> </Table> 114 P á g i n a

145 6. Análisis de resultados Hemos visto paso a paso cómo se ha desarrollado la solución móvil objeto de este proyecto. La interfaz de usuario es una interfaz Fiori, que proporciona una experiencia sencilla y fácil de utilizar, a través de varios tipos de dispositivos: escritorio, tabletas o teléfonos inteligentes. En este apartado se van a exponer unas imágenes gráficas a modo de ejemplo de cómo es el resultado final de la aplicación desarrollada. Al iniciar la aplicación se muestra en forma de iconos de acceso rápido la funcionalidad proporcionada, es decir, icono para navegar a los datos de los empleados, icono para navegar a las cualificaciones e icono de acceso a los cursos formativos. 115 P á g i n a

146 Si se selecciona el icono de acceso a los datos de empleados se accede a la pantalla dividida máster-detail. A la izquierda se presenta una lista de todos los empleados de la sociedad SES, con una breve descripción de cada uno: nombre, apellidos, y número de empleado. En la parte superior se encuentra la barra de búsqueda y el icono de navigation-back (vuelta a la página principal) En la parte derecha se encuentra la página de detail. Cuando se selecciona un empleado de la lista de máster, se navega automáticamente al detalle. En esta página, en la parte superior se muestra de nuevo la información breve del empleado, y debajo se observan tres iconos que permiten seleccionar la información que se quiere ver. De izquierda a derecha los iconos son de información personal, asignación organizativa y cualificaciones personales. 116 P á g i n a

147 En la parte inferior de la página de detail hay un botón de Editar Datos. Este es el control que permite actualizar los datos personales del empleado que esté seleccionado. Al pulsar dicho botón se despliega un formulario de actualización con etiquetas y cajas de texto para introducir la nueva información. 117 P á g i n a