ESTUDIO Y DEMOSTRACIÓN DE LA INTEGRACIÓN DE LAS PLATAFORMAS IBM PREMISES SERVER E IBM TIVOLI MAXIMO

Transcripción

1 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO EN INFORMÁTICA PROYECTO FIN DE CARRERA ESTUDIO Y DEMOSTRACIÓN DE LA INTEGRACIÓN DE LAS PLATAFORMAS IBM PREMISES SERVER E IBM TIVOLI MAXIMO AUTOR: Jaime Martín Talavera MADRID, Junio 2008

2 RESUMEN Los sensores y actuadores se han estado utilizando desde hace décadas en los entornos de producción para controlar y monitorizar procesos industriales críticos. En contraste a esto, actualmente se están desplegando de nuevas formas en cualquier área del negocio, gracias a la disminución de costes basados en las des-economías de escala, los avances en las tecnologías basadas en wireless, y los dispositivos inteligentes. La integración de la información de los sensores y los actuadores con los procesos de negocio está transformando la forma en la que se llevan a cabo los negocios. Con esta nueva generación de soluciones, es posible ayudar a las empresas para que tengan en todo momento detalle de su entorno operativo y sean capaces de responder dinámicamente a las condiciones cambiantes del punto de venta, la cadena de suministros, o la línea de manufacturado. Un sensor es un dispositivo, como un termómetro, un manómetro, o un contador de flujo, que detecta una condición física en el mundo real. Por otro lado, los actuadores son también dispositivos, como válvulas y switches, que ejecutan acciones como encender y apagar elementos, hacer ajustes en un sistema operacional, etc Por ejemplo, IBM ha añadido un sensor y actuador a algunos de sus portátiles ThinkPad. Este sistema detecta si se está llevando a cabo un nivel de aceleración peligroso y en ese momento, apaga el disco duro para evitar la pérdida potencial de datos. Todos estos sensores generan datos, y estos datos tienen que ser procesados por algo o por alguien. Este es el contexto principal del IBM WebSphere Premises Server (en adelante Premises). Bajo la familia de middleware WebSphere, este producto permite procesar cantidades enormes de datos generados por los sensores, y, cuando han sido procesados, decidir si se envían eventos a un sistema empresarial, como un ERP, o demandar una acción de un actuador, como por ejemplo un semáforo, para encender la luz verde. En el lado de los sistemas empresariales es donde se sitúa IBM Tivoli Maximo. Maximo es un sistema de gestión de activos desarrollado por MRO, que fue adquirida recientemente por IBM. Situado en la familia de gestión Tivoli, Maximo se ha colocado como líder en el cuadrante de EAM (Enterprise Asset Management) de Gartner 10 veces desde Maximo proporciona la capacidad de gestión del ciclo de vida así como gestión del mantenimiento exhaustivo para cualquier tipo de activos en una plataforma unificada. Con Maximo, es posible adquirir una visión más completa de todos los activos, sus condiciones y los procesos de trabajo que tienen que ver con ellos para conseguir una planificación y control más eficaces. Página i

3 El escenario primario del proyecto está enfocado a ser el siguiente: Un sensor fijado a un activo, reconoce algún tipo de evento y es enviado a Premises. Premises procesará el evento y la idea es que se le comunique a Maximo, para de esta forma por ejemplo, que sea posible hacer un inventario en tiempo casi real de los ítems que la compañía considera importantes y por lo tanto están monitorizados, aunque no sea únicamente el inventario, sino que también es posible llevar a cabo un control de flotas. El problema es que no existe una herramienta oficial para llevar a cabo esta integración, por lo que es el objetivo primario del proyecto, es decir, la integración de Premises con Maximo. La ventaja que supone la realización de un inventario basado en esta idea es que el inventariado es semi-automático. La labor de inventariar es una tarea muy tediosa, e incluso en algunos pequeños y medianos comercios que se ven obligados a cerrar durante uno o varios días para hacer inventario, lo que significa una paralización de su actividad económica durante ese periodo. La tarea principal del proyecto ha sido conocer y estudiar la arquitectura de Maximo y Premises, con el objetivo de contar consecuentemente con la capacidad de llevar a cabo las tareas requeridas para integrarlos y definir una guía con los pasos para hacer la integración entre ambos sistemas. Como resultado del trabajo realizado, se ha definido una guía de integración entre Maximo y Premises, así como conocer el funcionamiento de sistemas empresariales y servidores de aplicaciones, es decir, el WAS (WebSphere Application Server); WebSphere MQ, que es un sistema de mensajería basado en JMS, EJB s (Enterprise Java Beans) puesto que los agentes principales para definir la integración son EJB s. La arquitectura principal del proyecto está basada en el modelo cliente-servidor, ya que se supone que el cliente verá los cambios realizados por el evento detectado por el dispositivo en Maximo, y tanto Maximo como Premises actuar de servidores. Página ii

4 ABSTRACT Sensors and actuators have been used for decades in production environments to monitor and control critical industrial processes. But now they are being deployed in entirely new ways throughout the enterprise enabled by falling costs, advances in wireless technology and smart devices. The integration of information from sensors and actuators with business processes is transforming the way that business gets done; this next generation of solutions can help companies sense their operating environment and respond to dynamically changing conditions in the marketplace, the supply chain or on the manufacturing line. A sensor is any device, such as a thermometer, pressure gauge or flow meter, which detects a physical condition in the world. In turn, actuators are devices, such as valves and switches, which execute actions like turning things on or off or making adjustments in an operational system. For example, IBM has added an airbag- like motion detection system to some of its ThinkPad notebook computers. This system senses whether a dangerous level of acceleration is occurring, and turns off the hard drive, thereby helping to protect potentially valuable data. All of these sensors generate data and this data should be processed by something. That is the main context of the IBM WebSphere Premises Server. Within the family of WebSphere middleware, this product enables to process large amounts of data driven by the sensors, and when it has been processed, to decide whether to send to a business system, like an ERP or to send some orders to the actuators, like a semaphore, to turn on the green light. In the side of the business system is where it is possible to situate IBM Tivoli Maximo. Maximo is an Asset Management system developed by MRO, which was recently purchased by IBM. Situated in the IBM Tivoli Family, Maximo have been placed in the EAM (Enterprise Asset Management) Leader s Quadrant 10 times since Maximo provides comprehensive asset lifecycle and maintenance management for all asset types on a single unified platform. With Maximo, it is possible to gain insight across all of the assets, their conditions and work processes around them for better planning and control. The primary scenario of the project is intended to be as follows: A sensor attached to an asset, recognizes some event and it is sent to Premises. Premises will process the event and it is intended to send the event to Maximo, for having a near real-time inventory of the company with all of those assets that are important for the company, and these are Página iii

5 monitorized. The problem is that there is no an official tool or way to do this integration, so the main objective of the project is precisely that, to integrate Maximo with Premises. The advantage of making an inventory based on this idea is that the inventory is more or less semi-automatic. The labor of doing inventory is a very tedious task, and in some of small and medium business can involve closing the business for one day to do inventory, which means no profits that day. The primary task of the project has been to know the main architecture of Maximo and Premises, in order subsequently to have the capacity to carry out the requirement tasks to integrate both of them defining an integration guide. As a result of the work carried out, an integration guide for Premises and Maximo has been defined which improves the knowledge of business systems and application servers, like WAS (WebSphere Application Server), WebSphere MQ which is a JMS message based system, EJB s (Enterprise Java Beans), because the main agents are EJB s. The main architecture of the project is based on a client-server model, were it is supposed that a client will see the changes made by the device in Maximo, and use Maximo and Premises as servers which process the events required by the device. Página iv

6 Índice 1. Introducción El valor de los sensores y los actuadores RFID Antecedentes Historia El Espectro electromagnético M2M (Machine to Machine) Elementos fundamentales Estructuras típicas de arquitecturas M2M El modelo de referencia de IBM para soluciones M2M Soluciones de monitorización IBM WebSphere Premises Server Visión general IBM Tivoli Maximo Productos de la familia IBM Tivoli Asset Management Service Oriented Architecture (SOA) Introducción Perspectiva Service-Oriented Architecture: Un modelo conceptual Requisitos Estructura Diseño y desarrollo de SOA Web Services y SOA J2EE JMS JDBC Enterprise Java Beans (EJB) Un servidor de aplicaciones J2EE: IBM WebSphere Application Server Identificación de necesidades Integración. Concepto Descripción del sistema a desarrollar Página v

7 2.3 Alcance del sistema Tipología de usuarios finales Restricciones Plan de gestión Diagrama de actividades Descripción de las actividades Organigrama Tareas de cada integrante del equipo de trabajo Estimación de esfuerzo de cada integrante Presupuesto Estudio de las arquitecturas IBM WebSphere Premises Server El modelo de la solución RFID de IBM WebSphere RFID Premises Server WebSphere Premises Server IBM Tivoli Maximo Asset Management Conceptos básicos Estructura de ejecución de Maximo Estructura de la configuración de Maximo Arquitectura de Maximo Asset Management Maximo Enterprise Adapter Preguntas de Maximo Integración Premises Maximo Parte Premises Crear un server profile Configurar el server profile Probar la configuración Instalar el BIRT runtime Crear un enterprise application project Copiar los ficheros JAR requeridos Crear un Java utility Project Página vi

8 5.1.8 Modificar las dependencias J2EE del Java utility Project Crear la clase Java de utilidad Crear un Task Agent MDB Configurar el WebSphere Premises Server Creación del proyecto Web Modificar las dependencias J2EE del proyecto Web Crear el servlet Creación y definición del output channel Parte Maximo Prerrequisitos Integración Pruebas Plan de Pruebas Entorno de pruebas o certificación Tipos de Pruebas Resumen de pruebas Conclusiones Bibliografía ANEXO I. Instalación Premises v ANEXO II. Instalación Maximo v ANEXO III. Instalación Maximo for Transportation... 1 ANEXO IV. Métricas de configuración Hardware... 1 Página vii

9 1. Introducción El propósito de este proyecto es definir una guía de la integración de las plataformas software IBM Premises. En el presente documento se explica la arquitectura de ambas plataformas, y como resultado del estudio, se define la guía de integración aclarándolo con un ejemplo. En el año 2000, se crea en IBM el departamento Emerging Business Opportunity (EBO) para focalizarse en la capacidad de identificar, desarrollar y capitalizar negocios emergentes que puedan generar nuevas fuentes de mercados. Dentro de la EBO existen varias áreas, una de ellas es Sensores y Actuadores. Sensores y Actuadores se centra en permitir a los clientes conocer enormes cantidades de información relevantes a la identificación, ubicación y estado de los activos, productos y recursos entre otros. Esta nueva información proporciona una vista global de operaciones que, cuando son combinadas con cambios en los procesos y en las tomas de decisiones, permiten a los clientes transformar procesos claves como suministro, comunicaciones, equipamiento, mantenimiento y optimización de activos. IBM cuenta también con software muy útil para esta área. Desde una suite de gestión de activos hasta un middleware para monitorizar los sensores físicos implantados. La gestión de activos se lleva a cabo normalmente vía la suite de productos de IBM, IBM Asset Management, cuya pieza principal es IBM Maximo Asset Management, una herramienta muy completa que encaja en todo tipo de negocio. Para la monitorización y control de los lectores RFID 1, IBM cuenta con el Framework de RFID. La pieza clave de este framework es el IBM WebSphere Premises Server 6, que nos proporciona una arquitectura muy robusta capaz de procesar unas cantidades enormes de flujos de información suministrados por los lectores o por casi cualquier tipo de sensores. Si fuese posible conseguir una integración entre ambos, supondría un paso en cuanto a la eficiencia de los sistemas de gestión de activos. 1 Identificación por Radio Frecuencia Página 1

10 1.1 El valor de los sensores y los actuadores Un sensor es un tipo de transductor 2 que utiliza un tipo de energía, una señal de algún tipo y la convierte en una lectura con el propósito de transferir información. Ejemplos de sensores son un detector de volumen de la presión, un detector de movimiento, o un lector RFID. Un actuador es un sistema electrónico o mecánico que se utiliza para controlar un sistema. Un switch, una bomba, una válvula, un generador de carga o un semáforo son ejemplos de actuadores. Actualmente, los sistemas basados en sensores están incrementándose de forma muy importante en muchas industrias. Estos sistemas incluyen sistemas RFID - tanto activos como pasivos- sistemas basados en códigos de barras, GPS y Wi-Fi. En estos sistemas, un sensor detecta una situación de cambio (por ejemplo la presencia de un tag que se puede leer) y crea el evento correspondiente. La lectura y el procesado de este evento pueden crear un valor añadido a un negocio. IBM es un pionero en la tecnología de sensores y es una empresa líder en IT y estrategia de negocios. La tecnología de sensores y actuadores de IBM se usa en una gran variedad de áreas, incluyendo: Gestión de activos en la cadena de producción, proporcionando una visibilidad de los activos del principio hasta el final, y mejorando la gestión de los inventarios. Trazabilidad de activos, trazando el ciclo de vida de objetos individuales. 2 Transductor, dispositivo que transforma el efecto de una causa física, como la presión, la temperatura, la dilatación, la humedad, etc., en otro tipo de señal, normalmente eléctrica. Página 2

11 Monitorización y gestión de activos, recuperando datos de los sensores remotamente a través de las redes de activos para monitorizar el estado, la condición y el uso del activo, para mejorar su uso. Seguridad y control de acceso, Proporcionando un mapa de personas y activos para asegurar la seguridad en áreas de peligro (por ejemplo, en plantas nucleares, refinerías u otras áreas industriales, en las cuales la estancia debe estar estrictamente controlada). La pieza central de la solución de sensores y actuadores de IBM es IBM WebSphere Premises Server. Aunque el WebSphere Premises Server se utiliza de forma primaria para gestionar redes RFID, es una plataforma a través de la cual es posible gestionar cualquier tipo de sensores y de datos. 1.2 RFID RFID (siglas de Radio Frequency IDentification, en español Identificación por radiofrecuencia) es un sistema de almacenamiento y recuperación de datos remoto que usa dispositivos denominados etiquetas, transponedores o tags RFID. El propósito fundamental de la tecnología RFID es transmitir la identidad de un objeto (similar a un número de serie único) mediante ondas de radio. Las tecnologías RFID se agrupan dentro de las denominadas Auto ID (Automatic Identification, o Identificación Automática). Una etiqueta RFID es un dispositivo pequeño, similar a una etiqueta, que puede ser adherida o incorporada a un producto, animal o persona. Contienen antenas para permitirles recibir y responder a peticiones por radiofrecuencia desde un emisor-receptor RFID. Las etiquetas pasivas no necesitan alimentación eléctrica interna, mientras que las activas sí lo requieren. Una de las ventajas del uso de radiofrecuencia (en lugar, por ejemplo, de infrarrojos) es que no se requiere visión directa entre emisor y receptor Antecedentes En la actualidad, la tecnología más extendida para la identificación de objetos es la de los códigos de barras. Sin embargo, éstos presentan algunas desventajas, como son la escasa cantidad de datos que pueden almacenar, la imposibilidad de ser modificados (reprogramados), la necesidad de leer uno por uno y de necesitar una visión directa. La mejora obvia que se ideó, y que constituye el origen de la tecnología RFID, consistía en usar chips de silicio que pudieran transferir los datos que almacenaban al lector sin contacto físico (de forma equivalente a los lectores de infrarrojos utilizados para leer los códigos de barras). Página 3

12 1.2.2 Historia Se ha sugerido que el primer dispositivo conocido similar a RFID pudo haber sido una herramienta de espionaje inventada por Léon Theremin para el gobierno soviético en El dispositivo de Theremin era un dispositivo de escucha secreto pasivo, no una etiqueta de identificación, por lo que esta aplicación es dudosa. Según algunas fuentes, la tecnología usada en RFID habría existido desde el comienzo de los años 1920, desarrollado por el MIT y usado extensivamente por los británicos en la Segunda Guerra Mundial (fuente que establece que los sistemas RFID han existido desde finales de los años 1960 y que sólo recientemente se había popularizado gracias a las reducciones de costos). Una tecnología similar, el transponedor de IFF, fue inventada por los británicos en 1939, y fue utilizada de forma rutinaria por los aliados en la Segunda Guerra Mundial para identificar los aeroplanos como amigos o enemigos. Se trata probablemente de la tecnología citada por la fuente anterior. Otro trabajo temprano que trata el RFID es el artículo de 1948 de Harry Stockman, titulado "Comunicación por medio de la energía reflejada" (Actas del IRE, pp , octubre de 1948). Stockman predijo que "... el trabajo considerable de investigación y de desarrollo tiene que ser realizado antes de que los problemas básicos restantes en la comunicación de la energía reflejada se solucionen, y antes de que el campo de aplicaciones útiles se explore." Hicieron falta treinta años de avances en multitud de campos diversos antes de que RFID se convirtiera en una realidad El Espectro electromagnético Atendiendo a su longitud de onda, la radiación electromagnética recibe diferentes nombres. Desde los energéticos rayos gamma (con una longitud de onda del orden de picómetros) hasta las ondas de radio (longitudes de onda del orden de varios kilómetros) pasando por la luz visible cuya longitud de onda está en el rango de las décimas de micra. El rango completo de longitudes de onda forma el espectro electromagnético, del cual la luz visible no es más que un minúsculo intervalo que va desde la longitud de onda correspondiente al violeta hasta la longitud de onda del rojo. Cuando se habla de luz en sentido estricto, generalmente suele referirse a radiaciones electromagnéticas cuya longitud de onda es capaz de captar el ojo humano, pero técnicamente, el ultravioleta, las ondas de radio o las microondas también son luz, pues la única diferencia con la luz visible es que su Página 4

13 longitud de onda queda fuera del rango capaz de detectar con el ojo humano; simplemente son "colores" que nos resultan invisibles, pero puede ser detectado mediante instrumentos específicos. En las telecomunicaciones se clasifican las ondas mediante un convenio internacional de frecuencias en función al uso al que están destinadas: Clasificación de las ondas en telecomunicaciones Sigla Rango Denominación Empleo VLF 10 Khz. a 30 khz Muy baja frecuencia Audiofrecuencias LF 30 khz a 300 khz Baja frecuencia Radio, navegación MF 300 khz a 3 MHz Frecuencia media Radio de onda media HF 3 MHz a 30 MHz Alta frecuencia Radio de onda corta VHF 30 MHz a 300 MHz Muy alta frecuencia TV UHF 300 MHz a 3 GHz Ultra alta frecuencia Radio, TV, radar SHF 3 GHz a 30 GHz Súper alta frecuencia Radar EHF 30 GHz a 300 GHz Extra alta frecuencia Radar Página 5

14 Las ondas de radio pueden verse afectadas por el material en el cuál se están propagando. Un material es llamado RF-lucent o RF-friendly para una cierta frecuencia si permite que las ondas de radio pasen por él sin una pérdida sustancial de energía. Un material es denominado RF-opaque (Opaco) si bloquea, reflecta y dispersa las ondas de Radio Frecuencia. Nótese que un material puede permitir la propagación de ondas de radio frecuencia, pero con una pérdida sustancial de energía. Estos tipos de materiales son conocidos como RF-absorbent (Absorbente). La capacidad de absorbencia u opacidad de un material es relativa, puesto que depende de la frecuencia de las ondas. Esto significa que un material puede ser opaco a una cierta frecuencia, pero sin embargo puede ser RF-lucent a otra determinada frecuencia. Las propiedades de frecuencias de algunos materiales de ejemplo son mostradas en la tabla 2, después de una comparación de los tipos de frecuencia RFID. Los tipos de frecuencia RFID son los siguientes: Low frequency / Baja frecuencia(lf) High frequency / Alta frecuencia (HF) Ultra high frequency / Ultra Alta frecuencia (UHF) Microwave frequency / Microondas Low Frequency / Baja Frecuencia (LF) Frecuencias entre los 30 KHz y 300 KHz son consideradas bajas, y algunos sistemas RFID comúnmente usan un rango de frecuencias de 125 KHz a 134 KHz. Un sistema típico RFID de baja frecuencia opera a 125 KHz o a KHz. Los sistemas RFID de baja frecuencia generalmente utilizan tags pasivos, conteniendo un flujo de información entre el lector y la etiqueta generalmente bajo, y son especialmente aconsejables si el entorno de operación contiene metales, líquidos, suciedad, nieve o polvo. (Una característica muy importante de los sistemas LF). Los tags activos LF también están disponibles para los fabricantes. El rango de LF está aceptado mundialmente. High Frequency / Alta Frecuencia (HF) Los rangos de HF comprenden desde 3 MHz a 30 MHz, siendo los MHz la típica frecuencia usado por los sistemas RFID. Un sistema típico RFID de alta frecuencia utiliza tags pasivos, tiene una transferencia de datos desde el tag hasta el lector lenta y ofrece un Página 6

15 tratamiento muy bueno en la presencia de metales y líquidos. Los sistemas HF son también muy usados, especialmente en hospitales (donde no interfieren con el equipamiento existente). El rango de frecuencias HF está aceptado mundialmente. El siguiente rango de frecuencias es llamado very high frequency (VHF) y opera entre los 30 y 300 MHz. Desafortunadamente, ninguno de los sistemas actuales RFID operan en este rango. Por este motivo, no se adentrará más en este rango de frecuencias. Ultra High Frequency / Ultra Alta Frecuencia (UHF) Los rangos de UHF comprenden desde 300 MHz a 1 GHz. Un sistema típico pasivo UHF RFID opera a 915 MHz en Estados Unidos y a 868 MHz en Europa. Un sistema pasivo típico UHF RFID opera a 315 MHz y 433 MHz. Un sistema UHF puede también usar tags activos y pasivos y tiene una velocidad de transferencia de datos entre el lector y la etiqueta relativamente alta, pero no ofrece buenas prestaciones en la presencia de metales y agua (Realmente, en los casos de UHF de baja frecuencia como 315 MHz y 433 MHz). Los sistemas UHF RFID han empezado a ser expandidos hace relativamente poco, debido a los mandatos recientes de empresas privadas y entidades públicas acerca de RFID, como el Departamento de Defensa de Estados Unidos y fabricantes Nacionales e Internacionales. El rango de UHF no está aceptado en todo el mundo. Microwave Frequency / Microondas Los rangos de frecuencia de las Microondas superan el Gigahercio. Un sistema típico de Microondas RFID opera a 2.45 GHz o a 5.8 GHz, sin embargo, el primero es más común, se pueden usar tags pasivos y semi-activos, que tienen la mayor velocidad de transferencia entre el lector y el tag pero tiene un funcionamiento bastante pobre en la presencia de metales y líquidos. Debido a que la longitud de la antena es inversamente proporcional a la frecuencia, el tamaño de la antena de un tag pasivo operando en las frecuencias de las microondas es el más pequeño, lo que permite una disminución en el tamaño del tag, dado que el microchip del tag puede ser también muy pequeño. El rango de frecuencias de 2.4 GHz es llamado Industrial, Científico y Médico (Industry, Scientific, and Medical, ISM) y la banda de frecuencias está aceptada mundialmente. Existen restricciones internacionales aplicadas a las frecuencias en el que se puede usar la tecnología RFID. Por eso, algunas de las frecuencias expuestas anteriormente no Página 7

16 podrían estar disponibles en todo el mundo. En la tabla 1 se muestran algunos ejemplos de uso y restricciones de frecuencias, y la máxima potencia permitida. Tabla 1. Restricciones de bandas RFID País/ Región LF HF UHF Microondas Estados Unidos 125~134 KHz Europa Japón Singapur China 125~134 KHz 125~134 KHz 125~134 KHz 125~134 KHz MHz 10 watios effective radiated power(erp) MHz MHz MHz, 1 watio ERP o 4 watios ERP con una antena direccional de diez canales MHz, 0.1 watios ERP, Listen Before Talk (LBT) MHz, 2 watios ERP, LBT MHz, 0.5 watios ERP, LBT. No permitido. MPHPT (Ministry of Public Management, Home Affairs, Posts and Telecommunications) ha abierto una banda de MHz para experimentar MHz, 4 watios, ERP MHz, 4 watios ERP 2.45 GHz 2.45 GHz MHz MHz. 2 watios ERP GHz MHz No permitido. Posibilidad futura: MHz y/o MHz. SAC MHz, (Standardization 0.5 watios ERP Administration of China) es el encargado de formular las regulaciones RFID. Página 8

17 Tabla 2. Características de algunos materiales con respecto a RFID Material LF HF UHF Microondas Ropas RF-lucent RF-lucent RF-lucent RF-lucent Madera seca RF-lucent RF-lucent RF-lucent RF-absorbent Grafito RF-lucent RF-lucent RF-opaque RF-opaque Líquidos (algunos tipos) RF-lucent RF-lucent RF-absorbent RF-absorbent Metales RF-lucent RF-lucent RF-opaque RF-opaque Aceite de motor RF-lucent RF-lucent RF-lucent RF-lucent Productos de papel RF-lucent RF-lucent RF-lucent RF-lucent Plásticos RF-lucent RF-lucent RF-lucent RF-lucent (algunos) Champú/gel RF-lucent RF-lucent RF-absorbent RF-absorbent Agua RF-lucent RF-lucent RF-absorbent RF-absorbent Madera húmeda RF-lucent RF-lucent RF-absorbent RF-absorbent Cabe señalar también que en Noviembre de 2004, el ETSI (European Telecommunications Standards Institute) o Instituto Europeo de Estándares de Telecomunicaciones aprobó una nueva normativa que permitirá a los lectores operar en una gama de frecuencias mayores en la banda UHF, con el consiguiente aumento de alcance y de velocidad. Esta normativa entrará en vigor en Europa a principios de 2006, aunque en España de momento no está muy regulado, se prevé que haya que pedir una licencia temporal hasta que se apruebe oficialmente. Esta nueva regulación, conocida como ETSI , proporciona un rango de frecuencia adicional de 865 a 868 MHz en el cual los lectores RFID pueden operar. (Actualmente los lectores operan entre y MHz), incrementando la banda espectral de 250 khz a 3 MHz. El número de canales en el que los lectores pueden emitir, ha sido incrementado de uno a quince. La nueva banda es dividida en tres subbandas. Bajo las antiguas regulaciones, los lectores UHF estaban restringidos a medio watio de Potencia de Radiación Efectiva (ERP). Las nuevas regulaciones les permiten emitir hasta 2 Página 9

18 watios de ERP entre los y MHz; 0.5 watios ERP entre y 868 MHz; y 0.1 watios ERP entre 865 y MHz. Tabla 3. Comparación de la normativa EN con la actual ETSI EN vs ETSI EN (existente) ETSI (nueva) Frecuencias MHz MHz Ancho de banda 0.25 MHz 3.0 MHz Máxima Potencia 0.5 watios ERP 2.0 watios ERP Canales 1 15 Ciclo de Actividad 10% (6 min./hora) 97.5% o más Similar a la velocidad 30% de la velocidad Velocidad de datos en Estados Unidos de Estados Unidos Página 10

19 1.3 M2M (Machine to Machine) M2M (Machine to Machine o Máquina a Máquina) es un concepto genérico que indica el intercambio de información en formato de datos entre dos máquinas remotas sin intervención humana, es decir, sin que sea un operador el que se comunique con otra máquina, aunque a veces se traduce y ser refiere a Man-to-Machine, Machine-to-Man, Machine-to-Mobile y Mobile-to-Machine. En las compañías de móviles, este término se refiere a Mobile-to-Mobile y se utiliza para referirse a llamadas que no pasan por líneas fijas Elementos fundamentales Los elementos fundamentales que aparecen en todos los entornos M2M son los siguientes: Máquinas que gestionar: Vehículos, Alarmas domésticas, TPV (Terminal Punto de Venta), Contadores de agua/gas/ electricidad, paneles informativos en carreteras, máquinas vending, tele mantenimiento de ascensores, estaciones meteorológicas, Dispositivo M2M: módulo conectado a la máquina y que provee de comunicación con el servidor. Usualmente, el dispositivo M2M también consta de capacidad de proceso donde se ejecuta la aplicación de negocio. Por una parte implementa el protocolo para poder comunicarse con la máquina y por otra parte implementa el protocolo de comunicación para el envío de información. Servidor: Ordenador que gestiona el envío y recepción de información de las máquinas que gestiona. Habitualmente está integrado además con el core business de la empresa (ERP, Mapas GIS de trazabilidad de flotas de camiones, Sistema de pedidos, Centrales receptoras de alarmas, Helpdesk ) de modo que la información recibida pasa a ser parte crítica del negocio. Red de comunicación: pueden ser de dos naturalezas principalmente, a través de cable: PLC, Ethernet, RTC, RDSI, ADSL o bien a través de redes inalámbricas: GSM/UMTS/HSDPA, Wifi, Bluetooth, RFID, Zigbee, UWB, Estructuras típicas de arquitecturas M2M En la actualidad la mayoría de los sistemas M2M con elementos móviles, portátiles, o con gran dispersión geográfica utilizan los servicios de los operadores móviles para el transporte de datos y órdenes. Esta situación se debe a varios factores: Página 11

20 El relativamente bajo coste de las comunicaciones La gran disponibilidad geográfica del servicio, cubriendo prácticamente todo el territorio nacional y europeo La amplia disponibilidad a bajo coste del equipamiento de comunicaciones necesario, dada la estandarización de los servicios (módems GSM/GPRS) La ilustración siguiente representa los elementos y conectividad habitual en este tipo de sistemas. las siguientes: Ilustración 1. Elementos habituales de soluciones M2M En la figura anterior cabe destacar tres tipos de elementos cuyas funciones básicas son Clientes o dispositivos encargados de la interacción con los elementos a monitorizar o controlar. Servicios de telefonía móvil. Aplicaciones encargadas de recolectar, almacenar y explotar la información recogida por los clientes así como de tomar las decisiones de acción necesarias que los clientes debe ejecutar. Así como existe estandarización al nivel básico de transporte de datos (GPRS generalmente) no ocurre lo mismo a niveles más altos en la pila de comunicación, siendo Página 12

21 habitual que cada integrador o implantador utilice protocolos y sistemas propietarios para efectuar los cometidos propios de estas capas (garantía de entrega de mensajes, autenticación, etc.). Los modelos y arquitecturas basados en este tipo de soluciones, permiten el diagnóstico remoto y las comunicaciones M2M para monitorizar y regular equipamiento, procesos de producción, estado de activos, performance, grado de utilización y problemas de funcionamiento. Las funciones principales para las que se han diseñado son: Agregación de datos provenientes de sensores electrónicos instalados en equipos a controlar o midiendo parámetros ambientales. Análisis de los datos capturados frente a criterios predefinidos, ya sea a nivel local o centralizado. Creación y transmisión de alertas de acción basadas en el análisis de los datos. Por otro lado, este modelo y arquitectura tienen en cuenta las necesidades y requerimientos de diversas industrias (químicas, petróleos, utilities, transporte, fabricación y postventa, inmobiliaria,...). Son por tanto independientes de la topología de comunicaciones que puede variar según la implementación. Otros requerimientos importantes son la flexibilidad, escalabilidad y bajo acoplamiento entre los componentes de la arquitectura, permitiendo también la partición de la lógica de negocio en diferentes capas El modelo de referencia de IBM para soluciones M2M El modelo de referencia es una manera de representar de forma general los sistemas M2M para describirlos y analizarlos más fácilmente. Consta de un conjunto de dominios (domains) en los que se agrupan y describen tareas que el sistema debe efectuar para posteriormente poder asignarlas a los elementos o componentes más adecuados y en su caso definir sus especificaciones. A continuación se describe brevemente el modelo de referencia. La figura siguiente representa los dominios identificados en el modelo: Página 13

22 Ilustración 2. Dominios de referencia de IBM Sensor Domain El Sensor Domain considera el dominio de los elementos de monitorización y actuación. Estos elementos pueden ser sensores integrados o adosados a equipamiento diverso, como por ejemplo equipamiento de aire acondicionado, de fabricación, vehículos, electrodomésticos, máquinas de vending; o pueden ser sensores independientes que midan parámetros ambientales o relacionados con la actividad humana, sensores de temperatura, presión, detectores de presencia o intrusión, etc. Los elementos de actuación son capaces de variar algún parámetro del sistema que están monitorizando o de efectuar algún tipo de acción, por ejemplo emitir señales luminosas o acústicas Sensor Interface Domain El Sensor Interface Domain considera los diferentes tipos de interfaces que generalmente presentan los elementos del Sensor Domain. Estos interfaces dependen usualmente del tipo de industria en el que se utiliza el sensor o equipamiento y varían tanto en sus especificaciones físicas como en las lógicas. Así en el nivel físico podemos encontrar interfaces tanto cableados como vía radio con distintas tecnologías (PLC, analógico, RS232, USB, WiFi, Bluetooth, ZigBee,...). Y en el nivel lógico una gran variedad de protocolos (CAN, NMEA, ModBus, TCP/IP,...). Página 14

23 Gateway Domain El Gateway Domain considera el elemento que sirve de interfaz entre el mundo industrial de los sensores y actuadores y el mundo de las tecnologías de la información y comunicaciones. Se trata de un dispositivo inteligente, al que denominamos Edge Server. Este dispositivo debe ser autoconfigurable y/o permitir la gestión y configuración remota, y efectuará, en función de los requerimientos, parte o todas las funciones siguientes: Comunicación con los elementos del Sensor Domain tanto en captura de datos como en actuación. Filtrado y agregación de los datos capturados Ejecución de la lógica necesaria, tomando decisiones de actuación a nivel local Comunicación con los servidores a nivel central, tomando igualmente las decisiones de qué eventos comunicar y en qué momento WAN Domain El WAN Domain considera las redes y métodos de comunicación entre el Gateway Domain y los servidores corporativos. Estas redes podrán ser tanto cableadas como vía radio y podrán ser proporcionadas de manera general por un operador o estar dedicadas al sistema M2M de que se trate. Según lo anterior podemos encontrar entre las redes radioeléctricas redes celulares tipo GSM/GPRS, redes satelitales, WiFi,... Entre las redes cableadas el modelo contempla entre otras PLC, Internet, líneas dedicadas, Enterprise Application Domain El Enterprise Integration Domain considera la integración de los elementos específicos de los sistemas M2M con el resto de la arquitectura IT de la empresa. Para ello hace uso del concepto de Enterprise Service Bus encargado de las funciones siguientes: Conversión de formatos de mensajes Gestión de los flujos de los procesos Adaptación e integración de la información obtenida para su uso por otros componentes y aplicaciones corporativos: o o o Bases de datos y Data Warehouse Portales Sistemas de monitorización SCADA Página 15

24 o o o Sistemas ERP y CRM Aplicaciones específicas y legacy Sistemas de clientes o proveedores (B2B) Enterprise and Business Application Domain Este dominio considera las aplicaciones corporativas relacionadas con el análisis y explotación de la información capturada así como con las acciones a tomar a partir de ella. En él se consideran los siguientes tipos de aplicaciones, entre otras: Mantenimiento predictivo: análisis de la información recogida para detectar tendencias que permitan predecir a priori problemas de funcionamiento en los equipos monitorizados. CRM: identificación de problemas en los equipos o servicios proporcionados al cliente antes de que lo comunique. Gestión de la energía: optimización del consumo energético de los equipos monitorizados. Tarificación por consumo Management Domain El Management Domain es un dominio que comprende funciones diversas que aplican a varios de los restantes dominios. Considera la gestión de: Usuarios Dispositivos, incluyendo la configuración, gestión y actualización remota de los dispositivos Redes de comunicaciones Aplicaciones y servicios El Management Domain considera también las cuestiones asociadas a la seguridad tanto de las redes de comunicaciones como de los dispositivos. En este domino también se contemplan las herramientas para el desarrollo de las aplicaciones y el código necesario para los distintos componentes del sistema Soluciones de monitorización La recolección remota de datos a través de redes o la monitorización del estado, la condición y utilización de los activos gracias a los sensores permite a la monitorización de Página 16

25 flotas la posibilidad de llevar un seguimiento de los vehículos y poder utilizar sistemas disponibles, diagnosticar los vehículos para mejorar el tiempo operacional de los mismos, así como monitorizar el conjunto de la flota para conocer de una forma más detallada el estado de la misma y mejorar la utilización y de este modo, conseguir optimizarla. Unido a la monitorización de flotas, se presenta el caso de éxito de IBM en un proyecto para Norwich Union, una compañía aseguradora. Se basa en un modelo de negocio completamente nuevo a partir de la creación de un sistema de recolección de datos en tiempo real, utilizando una caja negra instalada en los vehículos de los clientes. El sistema cuenta con la capacidad de sentir y actuar, que recolecta información acerca de dónde, cuándo y con qué frecuencia el cliente conduce su vehículo. A alto nivel, el sistema procesa los datos recogidos de tal forma que la tasa de seguro reflejaría exactamente el uso del vehículo del cliente. La monitorización de activos puede suponer a los negocios la capacidad para identificar las áreas de servicio, reparación y mantenimiento, y gracias a ello, llevar a cabo acciones correctivas para reducir los fallos y el consiguiente tiempo de baja de los activos afectados. Página 17

26 1.4 IBM WebSphere Premises Server WebSphere Premises Server es una plataforma middleware para soluciones de sensores, independiente del sector del negocio. Básicamente es una plataforma capaz de recoger una enorme cantidad de eventos enviados por los dispositivos a los que está conectado (a través de lo que se denominan device agents), tratarlos adecuadamente, para lo cual dispone lo que se denominan task agents y actuar consecuentemente, ya sea enviando un evento a un dispositivo (por ejemplo, un actuador), o enviando información a través de lo que se denominan output channels (por ejemplo, un ). Internamente al Premises Server, existe el Data Transformation, que es el puente entre el MicroBroker y el WebSphere MQ. Data Capture and Delivery se comunica directamente con dispositivos lógicos y físicos, recolectando datos y llevando a cabo procesamientos básicos. El IBM Data Capture and Delivery Toolkit for WebSphere Premises Server permite personalizar los agentes con el producto. En complemento al IBM Data Capture and Delivery Toolkit for WebSphere Premises Server, WebSphere Premises Server incluye el WebSphere Premises Server Toolkit, que permite crear un entorno para crear y personalizar aplicaciones. El WebSphere Premises Server es la pieza central para las soluciones RFID de IBM, sirviendo como intermediario inteligente entre el mundo de los objetos físicos y dispositivos del Edge Domain y el mundo de los eventos abstractos RFID del Business Process Integration Domain Visión general El IBM WebSphere Premises Server es una aplicación basada en WebSphere que lleva a cabo las funciones del Premises Domain en la arquitectura de la solución RFID de IBM. El Premises Server procesa información RFID así como eventos de lectores RFID, controladores y equipo de automatización del Edge Domain, y permite el acceso de la información RFID al Business Processing Integration Domain. Página 18

27 Ilustración 3. Premises Server en el contexto de la solución RFID de IBM El Premises Server es capaz de interpretar y correlacionar altos volúmenes de datos de los dispositivos RFID que están conectados por medio del los Edge Controllers para lograr el aumento de la visibilidad en tiempo real de pallets o productos con tags fijados. La información de las lecturas puede ser integrada en los sistemas de negocio y compartida con el sistema de abastecimiento mejorando las capacidades de operación tanto con los partners como con los clientes. Por ejemplo, ver las ventas en tiempo real permite a los managers de ventas evaluar instantáneamente cómo se están vendiendo los productos. El minorista puede responder inmediatamente colocando anuncios en letreros luminosos con la intención de dirigir las compras a los productos que el sistema recomiende, o actualizando los precios en los sistemas. Una visión en tiempo real de las ventas puede también prevenir la falta de stock, resultando una mayor satisfacción del cliente y un aumento de las ventas. El WebSphere Premises Server sirve como un intermediario inteligente y un intérprete entre el mundo físico de los dispositivos RFID y el mundo de las aplicaciones IT vía un Business Integration Server. Página 19

28 Ilustración 4. Premises Server en el contexto de la arquitectura RFID Como producto que forma parte de la familia WebSphere, el WebSphere RFID Premises Server es un middleware basado en J2EE y en estándares abiertos. Permite a las soluciones RFID ser altamente personalizables y optimizadas para requisitos específicos de negocio. Conecta información de eventos RFID y lógica de procesado a otras aplicaciones del negocio en los sistemas back-end utilizando técnicas estándar y protocolos como Web Services, RMI/IIOP, JMS y JDBC. 1.5 IBM Tivoli Maximo IBM Maximo Asset Management es un producto que forma parte de la suite Maximo Enterprise, cuya principal tarea es la de gestión de activos y la optimización y planificación de servicios. Además, nos permite llevar tareas de mantenimiento de múltiples tipos de activos, así como conocer información de los costes de los activos de las empresas independientemente del tipo de industria. Página 20

29 Maximo Asset Management consta de seis módulos básicos que permiten a las compañías gestionar eficientemente sus activos, incluyendo equipamiento de producción, fábricas y transportes de activos, lo que supone una optimización de los objetivos de negocio. Estos sistemas incluyen: Gestión de activos Gestión de trabajo Gestión de servicios Gestión de subcontrataciones Gestión de materias primas Gestión de compras Funcionalidades de Maximo Asset Management Existen una serie de aplicaciones dentro de Maximo Asset Management que nos permiten llevar a cabo la gestión de los tipos mencionados anteriormente. Estas aplicaciones son las siguientes: Administration Assets Configuration Contracts Financial Integration Inventory Planning Preventive Maintenance Purchasing Reporting Resources Safety Work Orders Self-Service Module Security Página 21

30 Adicionalmente, es posible añadir otras funcionalidades: Maximo SLA Manager, permite supervisar las ofertas, los acuerdos y las entregas a nivel de servicio Maximo Incident & Problem Manager, para la gestión de incidencias IBM Maximo Change Manager, para la gestión de cambios de activos y estándares IBM Maximo Mobile Solutions, para proporcionar a los trabajadores acceso a Maximo desde dispositivos portátiles IBM Maximo Instrument Calibration Manager, para gestionar la calibración y las pruebas de la instrumentación IBM Maximo Asset Navigator, para mejorar la capacidad de localizar e identificar partes necesarias. IBM Maximo Adapter for Microsoft Project, que nos brinda la integración de Maximo con Microsoft Project IBM Maximo ERP Adapter, usado para integrar Maximo con Oracle o SAP Como se puede observar en la siguiente figura, Maximo Asset Management ha sido colocado como líder en los cuadrantes de Gartner durante más de 10 años. Página 22

31 Ilustración 5. Cuadrante Mágico de Gartner Productos de la familia IBM Tivoli Asset Management A continuación se hace mención y se lleva a cabo una breve descripción de los productos que componen la familia de Asset Management. IBM Tivoli Asset Management for IT Al igual que Maximo Asset Management, es una herramienta de gestión de activos, pero optimizada para las empresas IT, redefiniendo varios conceptos, como por ejemplo los activos. Permite gestionar el ciclo de vida de los activos IT controlando su coste con el objetivo de disminuirlo y disminuir el riesgo de las disconformidades IBM Maximo Spatial Asset Management es una solución de Geo-Posicionamiento y gestión de activos que permite al usuario visualizar los activos y servicios, en un contexto espacial, optimizando los recursos y facilitando las decisiones de negocio. Todo esto se lleva a cabo bajo una arquitectura robusta y moderna basada en Java, XML y servicios Web. Esta herramienta lleva implantada la tecnología de ESRI, ArcGIS Server, por lo que sus capacidades no se quedan tan solo en mapas estáticos, sino que permite querys del tipo "Muéstrame ubicaciones de aquellas unidades en un radio de X de la unidad que ha fallado que no se haya inspeccionado Página 23

32 este año", o "Muéstrame las unidades más probablemente afectadas por un evento en este área.". La tecnología GIS permite mejorar ciertos procesos de la gestión de activos y servicios, como por ejemplo: IBM Maximo for Life Sciences ayuda a la gestión de los activos IT en una única plataforma de acuerdo a la normativa FDA. Consolida las soluciones -gestión de activos y de servicios, calibración, calibración de equipos móviles, soporte CAPA- y lo integra con sistemas RFID, SCADA o LIMS. IBM Maximo for Nuclear Power permite llevar a cabo la gestión de los equipamientos, transporte y gestión de activos en una única plataforma. Proporciona a las compañías de las plantas nucleares una gestión más ágil, lo que ayudará a aumentar la productividad y eficiencia de sus activos críticos. Optimizado y parametrizado para plantas de energía nuclear. IBM Maximo for Oil and Gas al igual que Maximo for Nuclear Power, es una solución parametrizada de Maximo para las industrias petrolíferas y de gas. IBM Maximo for Service Providers ayuda a gestionar los activos para múltiples clientes. IBM Maximo for Service Providers ayuda a disminuir el coste total de almacenaje y a aumentar la rentabilidad, lo que implica una mayor satisfacción del cliente ya que se optimiza la gestión de los activos de los clientes. IBM Maximo for Transportation Solución parametrizada de Maximo para industrias de transportes. IBM Maximo for Utilities Solución parametrizada de máximo para industrias de distribución de agua, gas y electricidad. IBM Maximo Adapter for Microsoft Project Consiste en un plugin que permite la integración de Maximo con Microsoft Project permitiendo un flujo de datos bidireccional conservando la consistencia de los mismos en ambas plataformas. IBM Maximo Adapter for Primavera Al igual que Maximo Adapter for Microsoft Project, es un plugin que nos permite la integración de Maximo y del software Primavera, brindándonos una integración bi-direccional asegurando la consistencia de datos entre los dos sistemas. Página 24

33 Integra órdenes de trabajo, mantenimientos preventivos, Activos, Recursos y calendarios con Primavera. IBM Maximo Asset Configuration Manager Registra de forma precisa los cambios históricos y actuales de la configuración de los activos y sus componentes. Proporciona un cálculo en tiempo real de las configuraciones de los activos y los ciclos de vida de sus componentes, con beneficios como costes de operaciones reducidos. Maximo Asset Navigator gestiona de forma visual datos relativos a los activos para proporcionar fácil y rápidamente información de identificación de activos críticos. IBM Maximo Calibration proporciona todos los requisitos para la trazabilidad, todos los datos históricos de calibración, hojas de calibración e informes, automatizando los procesos de calibración para mejorar la efectividad y minimizar los costes de operación y a su vez permite a los técnicos llevar a cabo calibraciones móviles usando dispositivos portátiles Maximo Change Manager permite la gestión del planning, aprobaciones, despliegue y aprobación de procesos asociados con gestión de cambios. A su vez automatiza los cambios, aumentando la consistencia, proporcionando registros de validación para controles financieros y regulatorios. Maximo Compliance Assistance Documentation proporciona scripts usados para la validación de Maximo Asset Management. Utilizado para validar/revalidar el núcleo de la solución Maximo Asset Management como de Maximo Instrument Callibration Manager, consiste en una serie de plantillas de procesos de negocio. Maximo Discovery descubre dinámicamente todas las configuraciones hardware y software de una red, incluyendo su ubicación física. Controla los costes IT, y encuentra y registra dinámicamente todos los activos, y monitoriza las vulnerabilidades de la red. Maximo Enterprise Adapter permite una conexión y compartición rápida entre Maximo y otros sistemas así como un entorno completo de integración. Mantiene la agilidad de la gestión de activos y de trabajos de Maximo con el resto del negocio. Está basado en estándares de integración como XML, HTTP(S), JMS, y Web services, soportando web services síncronos y asíncronos, que pueden ser utilizados para hacer querys Página 25

34 en tiempo real sobre Maximo desde aplicaciones de terceros. Además, es posible definir reglas de mapeo, procesamiento y ruteo. IBM Maximo Enterprise Adapter (MEA) establece un puente entre Maximo y otros sistemas de negocio, y permite compartir información crítica con estos sistemas en tiempo real o de modo batch. Utilizando una arquitectura SOA (Service Oriented Architecture) para la integración, MEA soporta una integración rápida con los portales, sistemas y aplicaciones de negocio El MEA posee un entorno completo de integración que ayuda al proceso de desarrollo de la integración, configuración e implantación. Maximo Enterprise Adapter no es un módulo adicional, sino una configuración que se hace el producto, y que es posible hacerlo de muchas formas, entre otras, definiendo colas JMS desde WebSphere Maximo Mobile Solutions Extensión de Maximo a entornos Móviles (PDAs, Teléfonos Móviles, etc. ) Maximo Mobile SE Basado en el middleware de Syclo Agentry, de Syclo Maximo Mobile Work Manager SE Maximo Mobile Inventory Manager SE Maximo Mobile Auditor SE Maximo Integration Solutions Maximo Enterprise Adapter: adaptador SOA Maximo Enterprise Adapter for Oracle: Maximo <-> Oracle E-Business Suite Maximo Enterprise Adapter for SAP: Maximo <-> MySAP Maximo Integration Composer: Maximo <-> system management tools Maximo Online Commerce System Soluciones e-business para proveedores y departamentos de compras Página 26

35 1.6 Service Oriented Architecture (SOA) Introducción Service-Oriented Architecture (SOA) SOA es una arquitectura de software que permite la creación y/o cambios de los procesos de negocio desde la perspectiva de TI de forma ágil, a través de la composición de nuevos procesos utilizando las funcionalidades de negocio que están contenidas en la infraestructura de aplicaciones actuales o futuras (expuestas bajo la forma de webservices) y que se agrupan como servicios. Durante todo el ciclo de vida, SOA define también la infraestructura TI para permitir a las diferentes aplicaciones intercambiar datos para interactuar en los procesos del negocio. Estas funciones están muy levemente ligadas con los sistemas operativos y los lenguajes de programación que se utilizan en las aplicaciones. SOA separa las funciones en unidades separadas (servicios), que pueden ser distribuidas en una red y pueden ser combinadas y reutilizadas para crear aplicaciones. Estos servicios se comunican entre sí intercambiando datos de un servicio a otro, o coordinando una actividad entre dos o más servicios Perspectiva Uno de los principales objetivos de las empresas de desarrollo de software es buscar caminos para integrar los sistemas existentes para poder implementar soporte para los procesos de negocio que cubran la perspectiva del presente de los requisitos y necesidades de los sistemas. En este punto, existe una gran variedad de diseños alternativos que pueden ser usados para este fin, desde punto a punto, pasando por intercambio de datos electrónico (EDI) y otras. Actualizando tecnologías antiguas, como los sistemas basados en EDI, las empresas pueden hacer sus sistemas IT accesibles a clientes internos o externos, pero los sistemas resultantes no está probado que sean lo suficientemente flexible para responder a la demanda del negocio. Por todo eso, se requiere una arquitectura flexible y estandarizada para conseguir un soporte óptimo de las conexiones de distintas aplicaciones. SOA es una de estas arquitecturas. Unifica procesos de negocio estructurando aplicaciones enormes como colecciones de pequeños módulos llamados servicios. Estas aplicaciones pueden ser usadas tanto por personas de dentro y de fuera de la compañía, y las nuevas aplicaciones construidas a partir de la mezcla de servicios garantizan una mayor flexibilidad y uniformidad. La construcción de todas las aplicaciones compuestas por el mismo tipo de servicios hace que el logro del objetivo de conseguir una mayor flexibilidad y uniformidad sea mucho más fácil. Un ejemplo de esto sería la posibilidad de acometer una transacción con una compañía de reserva Página 27

36 de coches en el mismo sistema en el que estamos reservando un vuelo de otra compañía aérea. Los servicios SOA son unidades funcionales intrínsecamente desasociadas, y no tienen llamadas a otros embebidos en ellos. Típicamente implementan funcionalidades que la mayoría de las personas lo reconocerían como un servicio, como por ejemplo, ver una cuenta de un banco online, o hacer una reserva en una compañía aérea. En vez de que los servicios realicen llamadas embebidas a otros en el código fuente, los protocolos definen en cómo uno o más servicios pueden comunicarse con otros. Esta arquitectura confía en un proceso de negocio para enlazar los servicios, en un proceso llamado orchestration, que puede también adaptarse a nuevos requerimientos del sistema. Ilustración 6. Elementos de SOA Relativo a las prácticas típicas de reutilización de código vía separación de módulos (funciones), o vía separación de grupos predefinidos de funciones conocidos como clases, los objetos atómicos de SOA son comúnmente de 100 a veces mayores, y son asociados por el diseñador de aplicaciones usando el orchestration. En el proceso de integración, partes de código relativamente largos (servicios) son asociados en una organización no jerárquica (en contraste a la jerarquía de las clases), por un ingeniero de software o por un ingeniero de Página 28

37 procesos, utilizando una herramienta software especial que contiene una lista exhaustiva de todos los servicios y sus características, así como un registro de las decisiones del diseñador que el sistema puede usar en tiempo de ejecución. Teniendo a disposición todos estos metadatos, son suficientes para describir no sólo las características de estos servicios, sino también los datos que llevan. XML ha sido usado extensivamente en SOA para crear datos que están envueltos en un entorno descriptivo. Análogamente, los servicios en sí se definen típicamente por WSDL, y protocolos de comunicación por SOAP. Decidir si estos lenguajes son los mejores posibles para el trabajo, y si permanecerán como favoritos en el futuro, es actualmente una cuestión abierta. Lo que es cierto es que SOA es completamente dependiente de los datos y servicios que son descritos usando alguna implementación de metadatos que cumplen dos criterios. Los metadatos deben estar en una forma en la cual los sistemas pueden configurarse dinámicamente para mantener coherencia e integridad, y en una forma en la cual los diseñadores de los sistemas puedan comprender y gestionar estos metadatos. El objetivo de SOA es permitir que largos fragmentos de funcionalidad se agrupen juntos para constituir aplicaciones ad-hoc, que son construidas prácticamente enteras a partir de servicios software. Cuanto más grandes sean estos fragmentos, menos puntos de interface son requeridos para implementar cualquier set de funcionalidad; sin embargo, un fragmento grande de funcionalidad podría no ser lo suficientemente granular para ser reutilizado fácilmente. Cada interface lleva con ella una carga de procesamiento alta, lo que plantea una consideración en la elección de la granularidad de los servicios. La gran promesa de SOA es que el coste marginal de crear la n-ava aplicación es cero, dado que todo el software requerido ya existe para satisfacer los requisitos de otras aplicaciones. Sólo el integrador (orchestration) es requerido para producir una nueva aplicación. La clave está en que no hay interacciones entre las partes específicas con las partes en ellas mismas. En cambio, la interacción de servicios (todos ellos son pares desasociados) se especifican por los humanos en un camino relativamente ad-hoc con el propósito de ser fácilmente adaptables a las nuevas necesidades del negocio. Los servicios en sí mismos son desarrollados utilizando lenguajes tradicionales como Java, C#, C++, C o COBOL. Los servicios SOA están vagamente unidos, en contraste a las funciones en las que un linker las junta todas ellas y forma un ejecutable o una librería de vínculos dinámicos, entre otros. Página 29

38 En el futuro, los sistemas SOA podrían consistir en servicios de terceras partes combinados con otros servicios creados en la propia compañía. Esto tiene la potencial ventaja de reducir costes a la mayoría de los clientes, así como la estandarización en las industrias. En particular, la industria de viajes ahora cuenta con conjuntos de servicios y datos perfectamente definidos y documentados, suficientes para permitir a cualquier ingeniero de software crear un software de agencia de viajes usando únicamente los servicios software. Otras industrias, como la de recursos financieros, están haciendo progresos significativos en esta dirección. SOA es una arquitectura que cuenta con la orientación a servicios y es su principio fundamental de diseño. En un entorno SOA, servicios independientes pueden ser accedidos sin el conocimiento de la plataforma ni la implementación Service-Oriented Architecture: Un modelo conceptual Este concepto está basado en un estilo de arquitectura que define un modelo de interacción entre tres entidades primarias: El service provider, quien publica una descripción del servicio y la implementación del mismo, un service consumer, quien puede utilizar el uniform resource identifier (URI) para la descripción del servicio o puede buscar la descripción en un registro de servicios y así invocar al mismo. El service broker proporciona y mantiene el registro de servicios. Un modelo conceptual mostrando estas relaciones se observa en la Ilustración 7 a continuación. Ilustración 7. Modelo conceptual de SOA Página 30

39 1.6.4 Requisitos Para utilizar eficientemente SOA, uno tiene que comprobar los siguientes requisitos: La interoperabilidad entre los diferentes sistemas y lenguajes de programación proporciona la base de la integración en diferentes plataformas mediante un protocolo de comunicaciones. Un ejemplo de esta comunicación está basada en el concepto de mensajes. Usando mensajes a través de canales de mensajes decrementa la complejidad de la aplicación, permitiendo al desarrollador de la aplicación centrarse en la verdadera funcionalidad de la aplicación en vez de las necesidades de un protocolo de comunicaciones. El deseo de crear una federación de recursos. Establecer y mantener el flujo de datos hacia un repositorio de datos federados. Esto permite nuevas funcionalidades desarrolladas para referenciar un formato de negocio común para cada elemento de datos Estructura SOA define las siguientes capas de software: Aplicativa básica, sistemas desarrollados bajo cualquier arquitectura o tecnología, geográficamente dispersos y bajo cualquier figura de propiedad; De exposición de funcionalidades, donde las funcionalidades de la capa aplicativas son expuestas en forma de servicios (webservices); De integración de servicios, facilitan el intercambio de datos entre elementos de la capa aplicativa orientada a procesos empresariales internos o en colaboración; De composición de procesos, que define el proceso en términos del negocio y sus necesidades, y que varía en función del negocio; De entrega, donde los servicios son desplegados a los usuarios finales Diseño y desarrollo de SOA La metodología de modelado y diseño para aplicaciones SOA se conoce como análisis y diseño orientado a servicios. La arquitectura orientada a servicios es tanto un marco de trabajo para el desarrollo de software como un marco de trabajo de implantación. Para que un proyecto SOA tenga éxito, los desarrolladores de software deben orientarse ellos mismos a esta mentalidad de crear servicios comunes que son orquestados por clientes o middleware Página 31

40 para implementar los procesos de negocio. El desarrollo de sistemas usando SOA requiere un compromiso con este modelo en términos de planificación, herramientas e infraestructura. Cuando la mayoría de la gente habla de una arquitectura orientada a servicios están hablando de un juego de servicios residentes en Internet o en una intranet, usando servicios web. Existe un juego de estándares de los que se habla ligados a los servicios web. Incluyen los siguientes: XML HTTP SOAP WSDL UDDI Hay que considerar, sin embargo, que un sistema SOA no necesariamente necesita utilizar estos estándares para ser "orientado a servicios" pero es altamente recomendable su uso Web Services y SOA Web services pueden ser usados para implementar una arquitectura SOA. Un mayor foco de web services es hacer bloques funcionales accesibles por protocolos estándar de Internet, que son independientes de las plataformas y de los lenguajes de programación. Estos servicios pueden ser nuevas aplicaciones o aplicaciones ya existentes. Cada bloque SOA puede jugar uno o más de los tres roles siguientes: Service Provider: El service provider crea el web service y publica su interfaz y accede a la información del registro del servicio. Cada provider debe decidir qué servicios revela, cómo compensa la seguridad y la disponibilidad, fijar el precio de los servicios, o, si son gratis, como explotarlos para otro valor. El provider tiene también que decidir a qué categoría el servicio debería ser listado para un broker service y qué tipo de reglas y acuerdos son requeridos para la utilización del mismo. Service Broker: El service broker, también conocido como service registry, es el responsable de hacer la interfaz web del servicio y hacer disponible la implementación del servicio a cualquier solicitante del mismo. La implementación del broker decide el ámbito del broker. Los brokers públicos están disponibles en Internet, mientras que los Página 32

41 privados están sólo accesibles para una audiencia limitada, por ejemplo, usuarios de una intranet. Además, la capacidad de la información ofrecida tiene que ser decidida. Existen brokers que incluso catalogan otros brokers. Dependiendo del modelo de negocio, los brokers pueden intentar maximizar las peticiones de búsqueda, número de listados o la fiabilidad de los listados. El la especificación Universal Description Discovery and Integration (UDDI), define una vía para publicar y descubrir información de los web services. Service Requestor: El service requestor o Web service client ubica las entradas en el registro del broker utilizando varias operaciones de búsqueda y obliga al service provider para invocar uno de sus Web services. 1.7 J2EE Tanto la plataforma WebSphere Premises Server como IBM Tivoli Maximo Asset Management, se ejecutan con un entorno J2EE. A continuación se detallarán conceptos de dicha arquitectura y componentes fundamentales necesarios y relativos a la integración de ambas plataformas. Java Platform, Enterprise Edition o Java EE (anteriormente conocido como Java 2 Platform, Enterprise Edition o J2EE hasta la versión 1.4), es una plataforma de programación parte de la Plataforma Java para desarrollar y ejecutar software de aplicaciones en Lenguaje de programación Java con arquitectura de N niveles distribuida, basándose ampliamente en componentes de software modulares ejecutándose sobre un servidor de aplicaciones. La plataforma Java EE está definida por una especificación. Similar a otras especificaciones del Java Community Process, Java EE es también considerada informalmente como un estándar debido a que los suministradores deben cumplir ciertos requisitos de conformidad para declarar que sus productos son conformes a Java EE; no obstante sin un estándar de ISO o ECMA 3. Java EE incluye varias especificaciones de API, tales como JDBC, RMI, , JMS, Servicios Web, XML, etc. y define cómo coordinarlos. Java EE también configura algunas especificaciones únicas para Java EE para componentes. Estas incluyen Enterprise JavaBeans, servlets, portlets (siguiendo la especificación de Portlets Java), JavaServer Pages y varias tecnologías de servicios web. Esto permite al desarrollador crear una Aplicación de Empresa 3 ECMA: European Computer Manufacturers Association Página 33

42 portable entre plataformas y escalable, a la vez que integrable con tecnologías anteriores. Otros beneficios añadidos son, por ejemplo, que el servidor de aplicaciones puede manejar transacciones, la seguridad, escalabilidad, concurrencia y gestión de los componentes desplegados, significando que los desarrolladores pueden concentrarse más en la lógica de negocio de los componentes en lugar de en tareas de mantenimiento de bajo nivel JMS Se conoce con las siglas JMS, a la API 4 de mensajería Java bajo la plataforma de programación J2EE. Java Messaging Services (también conocida por sus siglas JMS) es la solución creada por SUN para el uso de colas de mensajes. Este es un estándar de mensajería que permite a los componentes de aplicaciones basados en la plataforma de Java 2 crear, enviar, recibir y leer mensajes. También hace posible la comunicación confiable de manera síncrona y asíncrona. El servicio de mensajería también es conocido como Middleware Orientado a Mensajes (MOM por sus siglas en inglés) y es una herramienta universalmente reconocida para la construcción de aplicaciones empresariales. Dicha API es parte integral de la versión 2 de Java. Existen dos modelos de la API JMS, los cuales son: Modelo Punto a Punto (point to point): Este modelo cuenta con solo dos clientes, uno que envía el mensaje y otro que lo recibe. Este modelo asegura llegar su mensaje ya que si el receptor no está disponible para aceptar el mensaje o atenderlo, de cualquier forma se le envía el mensaje y este se encola en una pila del tipo FIFO para luego ser recibido según haya entrado. Modelo Publicador/Suscriptor (Publish/Subscribe): Este modelo cuenta con varios clientes, unos que publican temas (tópicos) o eventos, y los que ven estos tópicos, a diferencia del modelo punto a punto este modelo tiende a tener más de un consumidor. 4 API: Application Programming Interface - Interfaz de Programación de Aplicaciones, es el conjunto de funciones y procedimientos (o métodos si se refiere a programación orientada a objetos) que ofrece cierta biblioteca para ser utilizado por otro software como una capa de abstracción. Página 34

43 Ambos modelos pueden ser síncronos mediante el método receive y asíncronos por medio de un MessageListener. Un ejemplo de un sistema comercial de mensajería JMS es IBM WebSphere MQ Capas de una aplicación JMS En la figura siguiente se muestran las capas en las que se divide una aplicación JMS. Ilustración 8. Capas de una aplicación JMS Como se muestra en la Ilustración 8, la aplicación no accede al proveedor de mensajería directamente, sino que el acceso se encapsula por una capa de código intermedia independiente del proveedor, además, estos objetos individuales se acceden vía JNDI 5. JMS oculta la mayoría de los detalles de la implementación de JMS y las capas del proveedor, de tal forma que el desarrollador Java puede construir una aplicación JMS que es casi neutral a la implementación del proveedor. Sin embargo, la persona que administra el proveedor JMS necesita conocer y comprende la capa de implementación JMS, puesto que la configuración se lleva a cabo en esta capa para hacer que la aplicación pueda funcionar con el proveedor. La especificación JMS describe la API de programación pero deja a elección del desarrollador los detalles de la implementación. No obstante, el administrador JMS debe conocer los detalles de la configuración, y estos detalles difieren de cada producto de cada proveedor. 5 JNDI: Java Naming and Directory Interface es una Interfaz de Programación de Aplicaciones para servicios de directorio. Esto permite a los clientes descubrir y buscar objetos y nombres a través de un nombre y, como todas las APIs de Java que hacen de interfaz con sistemas host, es independiente de la implementación subyacente. Adicionalmente, especifica una interfaz de proveedor de servicio (SPI) que permite que las implementaciones del servicio de directorio sean integradas en el framework. Página 35

44 1.7.2 JDBC JDBC es el acrónimo de Java Database Connectivity, un API que permite la ejecución de operaciones sobre bases de datos desde el lenguaje de programación Java independientemente del sistema operativo donde se ejecute o de la base de datos a la cual se accede utilizando el dialecto SQL del modelo de base de datos que se utilice. El API JDBC se presenta como una colección de interfaces Java y métodos de gestión de manejadores de conexión hacia cada modelo específico de base de datos. Un manejador de conexiones hacia un modelo de base de datos en particular es un conjunto de clases que implementan las interfaces Java y que utilizan los métodos de registro para declarar los tipos de localizadores a base de datos (URL) que pueden manejar. Para utilizar una base de datos particular, el usuario ejecuta su programa junto con la librería de conexión apropiada al modelo de su base de datos, y accede a ella estableciendo una conexión, para ello provee en localizador a la base de datos y los parámetros de conexión específicos. A partir de allí puede realizar con cualquier tipo de tareas con la base de datos a las que tenga permiso: consulta, actualización, creación, modificación y borrado de tablas, ejecución de procedimientos almacenados en la base de datos, etc Enterprise Java Beans (EJB) Los Enterprise JavaBeans (también conocidos por sus siglas EJB) son una de las API que forman parte del estándar de construcción de aplicaciones empresariales J2EE de Sun Microsystems (ahora JEE 5.0). Su especificación detalla cómo los servidores de aplicaciones proveen objetos desde el lado del servidor que son, precisamente, los EJBs: comunicación remota utilizando CORBA 6 transacciones control de la concurrencia eventos utilizando JMS servicios de nombres y de directorio 6 CORBA - Common Object Request Broker Architecture arquitectura común de intermediarios en peticiones a objetos, es un estándar que establece una plataforma de desarrollo de sistemas distribuidos facilitando la invocación de métodos remotos bajo un paradigma orientado a objetos. Página 36

45 seguridad ubicación de componentes en un servidor de aplicaciones. La especificación de Enterprise Java Bean define los papeles jugados por el contenedor de EJB y los EJBs, además de disponer los EJBs en un contenedor. Los EJBs proporcionan un modelo de componentes distribuido estándar del lado del servidor. El objetivo de los EJBs es dotar al programador de un modelo que le permita abstraerse de los problemas generales de una aplicación empresarial (concurrencia, transacciones, persistencia, seguridad,...) para centrarse en el desarrollo de la lógica de negocio en sí. El hecho de estar basado en componentes permite que éstos sean flexibles y sobre todo reutilizables. No hay que confundir los Enterprise JavaBeans con los JavaBeans. Los JavaBeans también son un modelo de componentes creado por Sun Microsystems para la construcción de aplicaciones, pero no pueden utilizarse en entornos de objetos distribuidos al no soportar nativamente la invocación remota (RMI). Existen tres tipos de EJBs: EJBs de Entidad (Entity EJBs): su objetivo es encapsular los objetos del lado del servidor que almacena los datos. Los EJBs de entidad presentan la característica fundamental de la persistencia: o o Persistencia gestionada por el contenedor (CMP): el contenedor se encarga de almacenar y recuperar los datos del objeto de entidad mediante el mapeo de una tabla de la base de datos. Persistencia gestionada por el bean (BMP): el propio objeto entidad se encarga, mediante una base de datos u otro mecanismo, de almacenar y recuperar los datos a los que se refiere, por lo cual, la responsabilidad de implementar los mecanismos de persistencia es del programador. EJBs de Sesión (Session EJBs): gestionan el flujo de la información en el servidor. Generalmente sirven a los clientes como una fachada de los servicios proporcionados por otros componentes disponibles en el servidor. Puede haber dos tipos: Página 37

46 o o con estado (stateful). Los beans de sesión con estado son objetos distribuidos que poseen un estado. El estado no es persistente, pero el acceso al bean se limita a un solo cliente. sin estado (stateless). Los beans de sesión sin estado son objetos distribuidos que carecen de estado asociado permitiendo por tanto que se los acceda concurrentemente. No se garantiza que los contenidos de las variables de instancia se conserven entre llamadas al método. EJBs dirigidos por mensajes (Message-driven EJBs): son los únicos beans con funcionamiento asíncrono. Usando el Java Messaging System, se suscriben a un tema (topic) o a una cola (queue) y se activan al recibir un mensaje dirigido a dicho tema o cola. No requieren de su instanciación por parte del cliente Un servidor de aplicaciones J2EE: IBM WebSphere Application Server IBM WebSphere Application Server (WAS, servidor de aplicaciones WebSphere), un servidor de aplicaciones de software, es el producto estrella dentro de la familia WebSphere de IBM. WAS está construido usando estándares abiertos tales como J2EE, XML, y Servicios Web. Varios laboratorios de IBM alrededor del mundo participaron en la creación de los productos run-time WebSphere y las herramientas de desarrollo. Este producto funciona con varios servidores web incluyendo Apache HTTP Server, Netscape Enterprise Server, Microsoft Internet Information Services (IIS), IBM HTTP Server para i5/os, IBM HTTP Server para z/os, y también IBM HTTP Server para el sistema operativo AIX/Linux/Microsoft Windows/Solaris. Cabe destacar que tanto Premises como Maximo corren bajo dicho servidor de aplicaciones. Página 38

47 2. Identificación de necesidades En esta etapa se define el problema a resolver y se fijan las normas a seguir para la dirección del proyecto. Se deben establecer los límites del proyecto, objetivos, restricciones y antecedentes. Cuanto más detallado sea este estudio, más sencilla será la realización del proyecto. 2.1 Integración. Concepto Conforme las empresas van definiendo e implantando Sistemas de Gestión certificables se hace más evidente la necesidad de racionalizar los esfuerzos, costes y recursos destinados a los mismos. Sobre todo cuando las normas de referencia en las que se basan, comparten requisitos en un porcentaje importante, y la metodología de gestión es al cien por cien idéntica. Por lo tanto el planteamiento de optimizar recursos, costes y esfuerzos vendrá por la integración común de todos aquellos conceptos cuya gestión tienen aspectos y requisitos comunes. El objetivo no es otro que evitar duplicidades, optimizar recursos y simplificar al máximo la gestión de todos los Sistemas. La Integración es el proceso a través del cual la organización aprende a introducir criterios y especificaciones en sus procesos y en sus sistemas de modo que satisfagan a todos sus clientes (internos, externos, institucionales, partes interesadas, etc.) de forma simultánea, ahorrando costes y esfuerzos, con un espíritu innovador, autocrático y comprometido con la mejora continua. El desarrollo e integración de software es la adaptación y mejora de lo que otros han realizado, pero buscando nuevos enfoques donde cubran los retos que los clientes nos proponen o las necesidades lo requieran. Se entiende por integración informática el intercambio por medios digitales de información elaborada tanto en cada uno de los sistemas software que deseemos integrar. La labor de integración software no es una labor sencilla, puesto que hay que conocer muy bien las arquitecturas de los sistemas que se están integrando, así como el control de mensajes e intercambio de información que se lleva a cabo entre ambos. Frecuentemente, la información o los datos están repartidos en múltiples sistemas de información, heterogéneos y autónomos, lo que constituye una dificultad a la hora Página 39

48 de aglutinar todos estos datos en un sistema centralizado. Sin embargo, el proceso de integración de dos o más sistemas cobra una importancia vital para la centralización de los datos para su consecuente procesado, pudiendo obtener de esta manera resultados más precisos y una visión de los datos en todos los sistemas empresariales del cliente. En resumen, y dicho de una forma burda, la integración se podría definir como el proceso de desarrollo para que dos o más sistemas hablen entre sí 2.2 Descripción del sistema a desarrollar El objetivo principal del proyecto es conseguir una integración de IBM Maximo Asset Management con WebSphere IBM Premises Server v6.1, definiendo una guía para llevarla a cabo. Para ello, habrá que cumplir una serie de sub-objetivos: Conocer y comprender la arquitectura de IBM Maximo Asset Management Conocer y comprender la arquitectura de WebSphere IBM Premises Server v6.1 Estudiar el comportamiento de IBM Maximo Enterprise Adapter Probar y testear la implantación, tanto con lectores simulados, como con lectores físicos En base al tiempo de desarrollo de los objetivos primarios, es posible que a estos objetivos se le añada la posibilidad de integrar el paquete Maximo Spatial Asset Management, un módulo para el geoposicionamiento de los activos de Maximo. 2.3 Alcance del sistema El alcance del sistema pasa por llevar a cabo una integración entre Premises y Maximo. Generalmente, esta integración tendrá un único sentido, pues es Premises quien recogerá los datos de los dispositivos y se los enviará a Maximo, de tal forma que éste lo tendrá en cuenta y lo incluirá en sus bases de datos. Página 40

49 Ilustración 9. Alcance del sistema Como se puede observar en la figura anterior, se dispone de dos máquinas virtuales, una de ellas cuenta con Premises v6.1, y la otra cuenta con Maximo. Estas dos máquinas se integrarán entre sí. El escenario primario de este proyecto es el siguiente: Un dispositivo recoge información de estado del activo al que está fijado (caso M2M), o del que obtiene información (caso RFID). Premises, gracias al Data Capture and Delivery, es capaz de tratar ese evento. Lo procesa y le envía un evento a Maximo. Maximo recoge dicho evento en el formato adecuado y lo plasma en sus bases de datos. Opcionalmente, cabe la posibilidad de que se extienda la integración al Maximo Spatial, módulo de Maximo basado en el Geo-Posicionamiento de los activos. La idea sería que el dispositivo proporcione información de posicionamiento a parte de la de estado a Maximo, y que este lo hiciera constar en Maximo Spatial. Página 41

50 2.4 Tipología de usuarios finales Dado que se trata de un proceso de integración de un middleware con un sistema de gestión de activos, se podría decir que los usuarios finales son los usuarios de Maximo, puesto que serán los que realmente verán los cambios producidos por la integración de ambos sistemas. 2.5 Restricciones Para llevar a cabo la realización de este proyecto, hay que contar con las restricciones que se detallan a continuación: A nivel temporal: En cuanto a lo referente al plazo de entrega del proyecto, éste deberá ser entregado antes de la primera semana de Junio de A nivel económico: Por lo relativo a requisitos Hardware, las tecnologías emergentes cuentan con un coste elevado, precisamente por su poco grado de impacto en los sistemas actúales. Desde el punto de vista Software, este es otra restricción, por lo que el precio de las licencias software tanto de Maximo como de Premises es bastante elevado, si bien se adquieren ambos paquetes, se acabará contando con un servidor de aplicaciones como el WAS, un sistema gestor de bases de datos como DB2 y un sistema de mensajería como WebSphere MQ, lo que significa que en caso de querer obtener estos sistemas middleware de forma separada, el precio sería mucho mayor. Aún así, el precio de las licencias software cobra un peso muy importante en este proyecto. A nivel software: La integración entre dos o más sistemas, no es una tarea sencilla. Esto es debido a que es necesario conocer las arquitecturas, cosa que no es siempre posible, es necesario diseñar módulos intermedios para la homogeneización de las plataformas heterogéneas. A nivel hardware: Referido no sólo a la propia limitación Hardware de los dispositivos, sino también a la arquitectura propia del servidor en el que se ejecuten Maximo y Premises. Es necesario contar con servidores potentes, puesto que estas aplicaciones son aplicaciones empresariales muy robustas, al precio de requerir mucha carga computacional. Página 42

51 3. Plan de gestión En este apartado se incluye el plan de gestión del proyecto. Un punto fundamental para la correcta realización del mismo. 3.1 Diagrama de actividades A continuación se muestra un diagrama de las distintas actividades de las que se compone el proyecto. Las actividades se numerarán de la forma WP XX.YY, donde XX corresponde a un número consecutivo referente a la tarea principal, e YY a la subtarea de XX. Página 43

52 Ilustración 10. Diagrama de actividades

53 3.2. Descripción de las actividades A continuación, se procederá a describir las actividades finales del proyecto, estas son aquellas actividades que no se dividan en otras sub-actividades Identificador de Actividad WP Nombre Introducción a la arquitectura de Premises Entradas Validación del director del proyecto Actividades Estudiar y comprender a grandes rasgos la arquitectura y el funcionamiento interno de Premises. Salidas Estudio del mercado Breve análisis y comprensión de la arquitectura de Premises Gestión Jaime Martín Talavera WP-01.02, es similar a WP-01.01, con la salvedad de que el estudio es de Maximo, por lo que se decide omitir Identificador de Actividad Nombre Entradas Actividades Salidas Gestión WP Instalación y pruebas Premises Documento de arquitectura y requisitos de Premises Hacer una instalación limpia en una máquina virtual de Premises Manual de instalación de Premises Jaime Martín Talavera WP-02.02, es similar a WP-02.01, con la salvedad de que la instalación es de Maximo, por lo que se omite. Página 45

54 Identificador de Actividad WP Nombre Estudio detallado Premises Entradas Documentos de instalación, instalación y funcionamiento de Premises Actividades Llevar a cabo un estudio en profundidad de la arquitectura de Premises Salidas Documento de análisis de arquitectura de Premises Gestión Jaime Martín Talavera Identificador de Actividad WP Nombre Estudio detallado Maximo Entradas Documentos de instalación, instalación y funcionamiento de Maximo Actividades Llevar a cabo un estudio en profundidad de la arquitectura de Maximo Salidas Documento de análisis de arquitectura de Maximo Gestión Jaime Martín Talavera Identificador de Actividad WP Nombre Desarrollo Entradas Documentos detallados de la arquitectura y funcionamiento de Premises y de Maximo Actividades Llevar a cabo la integración de Premises y Maximo utilizando varios métodos de comunicación entre ambos Salidas Documento explicativo de la integración de ambos sistemas. Configuración de los distintos parámetros, desarrollo de tareas y elementos de ejecución intermedios para la integración Gestión Jaime Martín Talavera Página 46

55 Identificador de Actividad Nombre Entradas Actividades Salidas Gestión WP-04 Pruebas Documentos de configuración de la integración y despliegue de la misma Someter al proyecto a un campo de pruebas Documento de pruebas, software de calidad Jaime Martín Talavera Página 47

56 3.3. Organigrama Posteriormente se mostrará el organigrama del proyecto Director Coordinador Jefe Proyecto Analista Programador Diseñador Ilustración 11. Organigrama del proyecto Como se observa en la Ilustración 11. Organigrama del proyecto, existe una colaboración entre el director y el coordinador del proyecto, mientras que la función de Jefe de Proyecto depende tanto del director como del coordinador, y a su vez, de éste depende el analista, el programador y el diseñador Página 48

57 3.4. Tareas de cada integrante del equipo de trabajo A continuación se mostrará una relación de tareas de cada integrante del equipo de trabajo: Identificador del integrante Nombre Tareas Coordinador David Contreras Bárcena Concretar la definición del proyecto Controlar/Supervisar el proyecto, junto con el director del mismo Supervisa los plazos de entrega Homogeniza la calidad de los proyectos Validación final del proyecto Identificador del integrante Nombre Tareas Director Javier L. de los Mozos Quiroga Dirigir el proyecto Facilitar las orientaciones adecuadas ante los problemas que vayan surgiendo Proponer una calificación al coordinador del proyecto Controlar/Supervisar el proyecto, junto con el coordinador Identificador del integrante Nombre Tareas Jefe de Proyecto Jaime Martín Talavera Gestiona el proyecto y es el máximo responsable del mismo Verifica el trabajo realizado por sus subordinados Identificador del integrante Nombre Tareas Analista Jaime Martín Talavera Analiza el contenido del proyecto, marcando pautas para la realización del mismo Página 49

58 Identificador del integrante Nombre Tareas Programador Jaime Martín Talavera Lleva a cabo toda la parte de programación del proyecto Instala el software necesario para llevar a cabo el proyecto Verifica la programación haciendo un banco de pruebas para comprobar la calidad del proyecto Identificador del integrante Nombre Tareas Diseñador Jaime Martín Talavera Analiza y define las interfaces que se deben llevar a cabo para la realización de la programación Página 50

59 3.5. Estimación de esfuerzo de cada integrante Para el proyecto, la estimación del esfuerzo de cada integrante es la que se muestra a continuación (mostrada en horas/hombre): COORDINADOR DIRECTOR JEFE ANALISTA PROGRAMADOR DISEÑADOR TOTAL PROYECTO WP WP WP WP TOTAL En este caso, se toman las actividades por la de más alto nivel, puesto que lo importante es observar en cada actividad, cuál es el número de horas empleadas. WP-01: Dado que es una introducción a las arquitecturas, se llevará a cabo tanto por el director, como el jefe de proyecto, analista, programador y diseñador. Esto es debido a que todos ellos deben conocer de qué se trata. Se estiman 105 horas, a razón de 4horas/día, 25 días laborables. WP-02: Instalación y pruebas: Las plataformas que se está tratando de integrar son plataformas muy complejas, y por lo tanto es necesario invertir 116 horas. WP-03: Desarrollo de la integración: Es la base del proyecto, donde se invierten un total de 285 horas, de las cuales 75 son del analista, puesto que es necesario conocer muy bien ambos sistemas, 20 del diseñador dado que es él quien debe definir las interfaces, y 180 del programador, puesto que hay que implantarlo WP-04: Pruebas: Esta tarea requiere la participación de todos los miembros, puesto que debe estar validado por todo el equipo. Se estima un total de 100 horas para el programador, 5 para el coordinador, director y analista y 10 para el diseñador, puesto que será éste quien valide las entradas y salidas del proyecto. Página 51

60 3.6. Presupuesto A continuación se mostrarán dos tablas, la primera con el desglose de las horas hombre invertidas por cada miembro del equipo y la segunda con la descomposición del precio por paquetes de trabajo del proyecto: DIRECTOR JEFE PROYECTO ANALISTA PROGRAMADOR DISEÑADOR HORAS/HOMBRE TARIFA 100,00 60,00 50,00 30,00 40,00 IMPORTE 1.700, , , , ,00 TOTAL ,00 HORAS TARIFA MEDIA IMPORTE WP , ,00 WP , ,00 WP , ,00 WP , ,00 TOTAL ,00 Página 52

61 4. Estudio de las arquitecturas El objetivo de este capítulo es definir y conocer las soluciones de arquitectura que se están estudiando y que posteriormente se irán a integrar. Página 53

62 4.1. IBM WebSphere Premises Server El WebSphere Premises Server consta de un entorno de ejecución J2EE y un entorno J2ME basado en OSGi. El entorno J2EE contiene el RFID Event Server y las aplicaciones asociadas con lógica de negocio personalizada. El RFID Event Server está soportado por los componentes de la infraestructura del Websphere Application Server, DB2 y WebSphere MQ El modelo de la solución RFID de IBM IBM ha creado un framework arquitectural para ilustrar hasta qué grado las soluciones RFID se modelan. En este framework, la solución RFID se divide en grupos lógicos que realizan funciones distintas en lo que se denominan component domains. Estos dominios se designan para permitir a las soluciones RFID la capacidad de desarrollo de estándares, como EPCglobal e ISO, mientras se aísla de los avances de la tecnología en otro dominio. Ilustración 12. IBM RFID Solution Domain Model La Ilustración 12 muestra la solución de IBM que incluye los siguientes dominios: Tagged Object Reader Edge Premises Business Process Integration Enterprise and Business Application Systems Management Página 54

63 Object Directory Los asuntos relativos a la seguridad y privacidad son parte también del modelo de dominio, pero se distribuyen entre todos los dominios y son específicos a cada uno Tagged Object Domain El Tagged Object Domain contiene los productos con un tag fijado en él, tanto en una cadena de suministros como en un almacén de activos o en cualquier ubicación del Asset que se requieren monitorizar, incluyendo el uso de sensores en los tags. Debido a que el objeto y el tag están unidos físicamente son considerados como componentes del mismo dominio. En contraste a otros dominios, la mayoría de los elementos en el Tagged Object Domain son móviles, por lo que se pueden mover a través de diferentes infraestructuras RFID. Esta restricción impone unos requisitos de interoperabilidad muy estrictos en los cuales estos elementos podrían ser localizados idealmente vía estándares abiertos Antenna and Reader Device Domain El dominio Antenna and Reader Device Domain es la interfaz entre el mundo físico de objetos, tags, radio frecuencias y demás y el mundo de sistemas de software. En el futuro, se espera la transferencia de una funcionalidad más sofisticada del Edge Domain a los Readers (por ejemplo, filtrado de eventos), haciendo a los lectores más inteligentes y capaces de manejar tareas más eficientemente Edge Domain El Edge Domain incluye la funcionalidad de filtrado y agregado de volúmenes de datos proporcionado por los Readers, soportando el análisis de datos y aplicando toma de decisiones locales e inteligencia. La arquitectura de este dominio necesita ser compatible con los lectores de varios fabricantes y debe esconder detalles individuales de las lecturas. En sistemas en los que no existe un usuario del dispositivo móvil o remoto, es imprescindible que el propio dispositivo sea capaz de autoconfigurarse y autorecuperarse en caso de fallo o de permitir realizar estas tareas remotamente con el objetivo de evitar al máximo las intervenciones locales que en general provocarían grandes desplazamientos. Adicionalmente es deseable poder modificar tanto la configuración del dispositivo como su software interno también remotamente, lo que dota de gran flexibilidad al sistema. Dada la gran diversidad de hardware de dispositivos que puede ser necesaria en función de los interfaces de los sensores y/o actuadores a los que se tenga que conectar, es deseable contar Página 55

64 con una plataforma homogénea y estándar sobre la que ejecutar la lógica de adquisición de datos, análisis local y control. La Open Service Gateway Initiative (OSGi) es un consorcio de más de 80 compañías cuyo objetivo es la definición de una infraestructura para la provisión desatendida de servicios a redes de ámbito local y microredes mediante redes de área extensa. OSGi define una arquitectura abierta y sencilla para la instalación y gestión de servicios sobre dicha infraestructura. OSGi puede definirse como un gateway entre el mundo embebido y el mundo de las tecnologías de la información. OSGi es independiente de hardware y de sistema operativo, es un framework basado en Java que se ejecuta sobre una máquina virtual. Es también independiente de la lógica de las aplicaciones y servicios que ejecuta, se limita a gestionar su ciclo de vida (instalación, arranque, parada, suspensión, borrado) controlando las dependencias e interacciones entre ellos. Toda esta gestión puede ser efectuada remotamente de forma transparente. Es simple de usar, dispone de interfaces Java para todas sus funciones y a su vez es fácil adaptar aplicaciones Java existentes para su uso bajo OSGi. Por todo lo anterior IBM considera siempre en sus soluciones M2M es uso de OSGi en el Edge Device. Las funciones del Edge Domain se implementan típicamente en un dispositivo de bajo coste para utilizar tecnologías embebidas para establecer una pila software en el borde de la infraestructura RFID. Para permitir la manejabilidad de un sistema de producción RFID, los aspectos de despliegue son otro aspecto clave que debe ser solucionado. Las actualizaciones softwareen el Edge Domain pueden ser implantadas automáticamente Premises Domain El dominio Premises es el intermediario entre las aplicaciones de negocio y el Edge Domain. El Premises Domain filtra y agrega, monitoriza y escala los eventos RFID para detectar operaciones de negocio críticas, mejorando la toma de decisiones. También tracea y loguea toda la información importante acerca de los productos y ubicaciones y gestiona componentes inferiores en otros dominios, como lectores o controladores RFID. El Premises Domain trata con los eventos en un nivel superior al Edge Domain, esto es, los eventos son importantes en el contexto de Business operation or process. Este domain Página 56

65 puede almacenar datos, e interactúa con los sistemas back-end a través del Business process integration. La lógica de negocio puede ser específica para los requisitos operacionales de premises. Como un ejemplo, un centro de alimentos puede tener diferente lógica de negocio que un centro de distribución de hardware, aunque pertenezca a la misma cadena de distribución y sean parte de la misma jerarquía Business Process Integration Domain El Business Process Integration Domain conecta la infraestructura RFID con las aplicaciones empresariales. Mientras que otros dominios proporcionan un nivel razonable de funcionalidad sin modificaciones, el Domain Business Process Integration requiere típicamente una personalización para concordar con un entorno empresarial concreto. Por eso, este dominio se describe como un toolbox para la integración de negocio. Una funcionalidad clave del Business Process Integration Domain es su capacidad de actuar como un hub de negocio-a-negocio para transacciones automáticas entre Partners comerciales. Como el resto de la infraestructura RFID, el aviso de un movimiento de un producto (por ejemplo, una entrega), este dominio formatea y envía un mensaje (por ejemplo, una noticia de entrega) al partner apropiado. El Business Process Integration Domain no conecta únicamente con las aplicaciones existentes, sino que también abre nuevos caminos de hacer y gestionar negocios vía Business Process Transformation and Business Performance Management Enterprise and Business Applications Domain El Enterprise and Business Applications Domain incluye las aplicaciones existentes que requieren información acerca de los movimientos de los productos capturada por la infraestructura RFID. Estas aplicaciones corresponden a los requisitos individuales de un negocio. Este dominio incluye sistemas que ayuden a ordenar, gestionar o proveer bienes y puede ser mejorado sustancialmente siendo capaz de monitorizar los movimientos de los productos automáticamente. Ejemplos de estos tipos de sistemas son la Automatización de Procesos, Gestión de inventario, Enterprise Resource Planning (ERP), Sistemas de ejecución de Página 57

66 manufacturado, sistemas de ejecución de suministros, sistemas de Warehousing, gestión de Merchandise, sistemas de almacenamiento, etc Object Directory Domain El Object Directory Domain proporciona información acerca de los objetos físicos, que, usando su ID único como su clave de búsqueda, es posible identificarlos. Permite la obtención rápida de los datos de los productosy proporciona un Framework para permitir a las compañías la compartición de información de productos de forma segura con Partners. La EPCglobal Network consta de lo siguiente: Object Naming Service (ONS) Electronic Product Code Discovery Service (EPCDS) Electronic Product Code Information Service (EPCIS) La EPCglobal Network es un ejemplo de un Object Directory Domain. Este dominio proporciona típicamente tres tipos de información de un producto: Core product information Manufacturing time information Life cycle history information Systems Management Domain Este dominio permite a los clientes mantener los sistemas RFID disponibles. Brinda la posibilidad de desplegar y gestionar aplicaciones remotamente en un entorno distribuido, incluyendo la capacidad para monitorizar, configurar o actualizar el software y el firmware remotamente en activos desplegados, como antenas, lectores y servidores. En este dominio es posible incluir un cuadro de mando central a través del cual es posible monitorizar activos y recibir alertas cuando los lectores, las antenas o los servidores se caigan Security and Privacity Management Como parte de un sistema integral de gestión de datos, los sistemas TI deben tener en cuenta aspectos de seguridad y subsidiar posibles brechas de privacidad. Una gestión efectiva de la seguridad y la privacidad permite a los clientes extender la infraestructura de seguridad existente al nivel del lector vía el Electronic Product Code (EPC) Network. La infraestructura debe proteger los datos almacenados a la vez que los datos que están en tránsito. Página 58

67 4.1.2 WebSphere RFID Premises Server 6.0 A continuación se hará un repaso de la arquitectura del antiguo WebSphere RFID Premises Server 6 para posteriormente pasar a la arquitectura del Premises 6.1 Como se muestra en la figura anterior, existen dos colas de entrada a Premises y otras dos de salida. Cada par de colas de Entrada/Salida corresponde a cada uno de los dominios adyacentes al Premises Domain. Todas ellas están basadas en el sistema de mensajería JMS WebSphere MQ. La primera cola de entrada es la denominada EDGE.IN.Q, que recoge los eventos procedentes del Edge Domain. Posteriormente, el Edge Input Handler recoge el evento y se lo envía al Event Service, el cual, gracias al Task Processing Channel, introduce el evento en la tabla de TASK.Q. Las tareas aplicables a dicho evento, se ejecutarán y tratarán al evento tantas veces como sea requerido. Cuando una de las tareas manda salir un evento por un canal de salida, el evento es enviado al Output Channel Router, que colocará el evento en el canal correspondiente, tanto JMS (para enviarlo por colas java a EDGE.OUT.Q, o lo que es lo mismo, a un dispositivo), como por la cola CONTROL.OUT.Q, cola encargada de controlar Página 59

68 aplicaciones de negocio. Al igual que por JMS también puede ser enviado un evento por un canal HTTP, haciendo uso del HTTP POST, que puede ser utilizado bien para utilizar un WebService o bien un servlet HTTP que esté a la escucha de transacciones. Por último, el output channel restante es vía , configurando el Premises con un servidor SMTP para poder enviar s con los eventos que se den en los task. Existen eventos que tienen asociadas unas salidas predefinidas, por lo que no es necesario que sean procesados por ninguna tarea (task), de tal forma que en el momento que lo recoge el Router, es directamente dirigido a un output channel. La cola de entrada CONTROL.IN.Q es la cola predefinida para el canal de salida para el Business Integration Cambios de Premises Server 6 a Premises Server 6.1 Para poder conocer mejor la arquitectura del Premises Server 6.1, se detallan en este apartado los cambios realizados de la versión anterior a ésta Nombre del producto WebSphere RFID Premises Server pasa a llamarse WebSphere Premises Server Instalador WebSphere Premises Server utiliza ahora un asistente de instalación que instala todos los prerrequisistos software y el producto WebSphere RFID Device Infrasctructure support El soporte para WebSphere RFID Device Infrastructure se ha eliminado en esta versión Soporte del Device Manager Server WebSphere Premises Server v6.1 no incluye el Device Manager Server. Si tenemos el Device Manager Server para WebSphere Premises Server 6.0, es posible utilizarlo con esta versión de Premises Server Bundle Loader En vez de usar el Device Manager Server, esta versión utiliza un bundle loader, que es un bundle OSGi que ubica y lista todos los bundles y lleva a cabo la acción especificada en cada bundle de la lista una vez que es iniciado. Página 60

69 Event flow WebSphere Premises Server utiliza un nuevo formato de eventos, llamado IBM Sensor Event, y tiene un nuevo flujo de eventos que soporta el WebSphere Application Server service integration bus (SIBus) Location Awareness Services for WebSphere Premises Server El Location Awareness Services for WebSphere Premises Server (LAS) se incluye en esta versión del Premises Server. LAS proporciona una consola visual que automáticamente ubica tags activos que son monitorizados en tiempo real. Personal o activos pueden ser de esta forma monitorizados en zonas de peligro virtuales. Así, el LAS mandará alertas de seguridad si los activos o el personal no están cualificados para entrar o salir de dichas áreas Print Profiles Esta versión introduce una nueva variedad de impresión utilizando perfiles para enviar y recibir mensajes vía el WebSphere Application Server service integration bus EPCIS Connector sample application Esta versión proporciona una aplicación EPCIS de ejemplo para convertir lecturas de tags y eventos genéricos de lectura a eventos EPCIS XML Cambios en la consola administrativa de WebSphere Premises Server La consola administrativa de WebSphere Premises Server añade el soporte a los exploradores Mozilla Firefox e Internet Explorer 7.0. WebSphere Premises Server usa Business Intelligence and Reporting Tools (BIRT), un sistema de reporting basado en Eclipse y de código abierto, para ejecutar y mostrar informes de lecturas de tags del Premises Tivoli Provisioning Manager for Software WebSphere Premises Server proporciona el Tivoli Provisioning Manager for Software SPD files for WebSphere Application Server, DB2 for Linux, UNIX, and Windows and WebSphere MQ running on Windows platforms only WebSphere Premises Server 6.1 A continuación se muestra una figura con el detalle de la arquitectura del Premises Server 6.1 Página 61

70 DTS DTS o Data Transformation Service, es un conjunto de objetos y utilidades para permitir la automatización de extracción, transformación y carga de operaciones de o desde una base de datos. Los objetos son paquetes DTS y sus componentes y utilidades son DTS tools. Con la versión 6.1 de Premises, las transformaciones del MicroBroker han sido eliminadas, así como los eventos genéricos no tienen que ser transformados. Los eventos de entrada son almacenados en DC.in.Q. El DTS se conecta directamente con el Data Capture vía MQ, por otra parte, los eventos de salida son encolados en DC.out.Q y publicados en el MicroBroker en el topic <edge.id>/dccontroller/generic/event/to/datacapture. Este topic es recuperado gracias a la propiedad del mensaje JMS target= <edge.id>/dccontroller/generic/event/to/datacapture Gateway (GW) Este componente es el punto de entrada para los eventos genéricos en el SI-Bus. Para explicar de una forma más detallada este elemento, se mostrará el sistema de eventos de Premises. Página 62

71 Como se puede observar en la figura anterior, el Gateway se encuentra entre el administrador de eventos OSGi, el dispositivo y el WebSphere SI-BUS, ya que es el punto de entrada para quien quiere publicar eventos de sensores al bus de Premises Server SI-bus. Por defecto, el Data Capture publica eventos al Microbroker, y el Microbroker envía los eventos al WebSphere MQ. En esta versión, se proporciona un servlet y un web service para publicar los eventos al Premises SI-Bus Puntos de entrada al Event Gateway Existen básicamente tres puntos de entrada al Event Gateway, como se muestra a continuación: Vía MQ, se ha añadido un Queue Manager para Premises v6.1 (IBM.DC.QM), a su vez se añaden las siguientes colas: o DC.IN.Q@IBM.DC.QM o DC.OUT.Q@IBM.DC.QM o Enterprise.IN.Q@IBM.DC.QM o Enterprise.OUT.Q@IBM.DC.QM Vía servlet, como se ha comentado anteriormente, para publicar los eventos al SI-Bus Vía web services Página 63

72 Interfaces del Event Gateway Las interfaces del Event Gateway son las siguientes: WebSphere MQ o DC.IN.Q@IBM.DC.QM o Enterprise.IN.Q@IBM.DC.QM Servlet o enttype>&eventtopic=<topicname>&eventxml=<eventstring> Web Service o Endpoint o WSDL El servlet del event Gateway, así como los Web Services son únicamente para eventos de sensores hacia premises server (y al negocio). En caso de que el usuario desee enviar eventos de bajada a Premises, sería necesario publicar los mensajes a Enterprise.IN.Q@IBM.DC.QM o utilizar las APIs de Premises Server Formato de los eventos del Gateway Los eventos enviados al Gateway son xml del tipo ibmsensorevent. El Gateway los convierte a objetos ibmsensorevent y los publica en el WebSphere SI-bus. En caso de no poder llevar a cabo dicha conversión, el Gateway lo publicará en el topic dead letter Service Integration Bus (SI-Bus) Un Bus es un conjunto de servidores y clústeres interconectados los cuales se han identificado como miembros del bus, aunque la configuración por defecto es un sistema en un bus único. El Service Integration Bus es parte de la infraestructura del WAS, con el motor Publish/Subscribe, puede estar basado en colas o en topics, requiere lo que se conoce como Activation Specifications, para activar el bus, estos Activation Specifications están vinculados a los TaskAgents (MDBs) así como a los topics o a las colas. Los mensajes llegan al topic o a la cola vinculada cuando se ejecuta el método onmessage() del TaskAgent. Página 64

73 El Service Integration Bus soporta aplicaciones basadas en mensajes o bien en serviceoriented architectures (SOA). Dentro del SI-bus, existen los dos buses siguientes: AMIT: Es un bus para el motor AMiT IBMSENSOREVENT: Bus para manejar los IBM sensor events Eventos manejados por Premises Server Para manejar correctamente los eventos en Premises Server, cuando se produce un evento, habría que responder a las siguientes preguntas: Quién vio el evento? Qué fue el evento? Dónde se dio el evento? Cuándo fue visto el evento? Para contestar estas preguntas, IBM creó un formato de eventos propietario basado en XML y utilizado en las versiones 6.0.x y anteriores de Premises. Estos eventos solo se utilizaban únicamente en soluciones RFID, por lo que el utilizarlos para comunicar otro tipo de sensor era muy difícil por no decir imposible, además el mensaje XML tendía que ser parseado múltiples veces durante el procesado del evento. Sin embargo, en Premises 6.1, se comienzan a utilizar eventos genéricos vistas todas estas limitaciones de los mensajes propietarios. Estos mensajes soportan cualquier tipo de eventos, no únicamente eventos RFID, además de que el mensaje XML se utiliza una única vez cuando entra en el Gateway. La representación de un evento es un mensaje XML de entrada o salida al Premises Server. Este mensaje XML es lo que se conoce como Common Base Event (CBE), que no es más que una implementación de IBM del estándar Web Services Distributed Management Event Format (WEF). WEF proporciona la instrumentación para construir aplicaciones y se está utilizando actualmente en varios productos de las familias WebSphere, DB2 o Tivoli. Además, las clases Java que representan a los Common Base Events tienen una gran facilidad de convertirlos a XML. Los mensajes de Premises tienen el formato de XML CommonBaseEvents (CBE), mientras que el formato de los mensajes del DataCapture, son JAVA Dictionary (Map) Página 65

74 El agente para transformar los eventos, recibe los mensajes basados en CBE-XML de Premises y son transformados a objetos Map/Dictionary cuando entran en el DataCapture. Por otro lado, los objetos del DataCapture que son enrutados a Premises, se transforman a CBE-XML objects Comunicación con el DataCapture A continuación se mostrará una figura donde se observa de forma gráfica la comunicación de Premises con el DataCapture Ilustración 13. Comunicación Premises con DataCapture Como se puede observar en la figura anterior, los eventos que entran al DataCapture desde Premises, entran como CBE-XML. Este evento es recibido por el TransformationAgent y lo convierte a JAVA objects (IBMSensorEvent). El IBMSensorEvent se convierte a un objeto JAVA Map, que es convertido a un diccionario y publicado en el bus EventAdmin. Por otro lado, el agente publica el evento en el como topic topic/dictionary, el cual tiene que enrutarse a Premises. El TransformationAgent se suscribe para todos los topics para recoger todos aquellos eventos que tienen que ser enrutados a Premises. A su vez, toma los Mappings Página 66

75 del diccionario y crea un IBMSensorEvent desde él, posteriormente lo convierte a un CBE-XML y lo publica en el NotificationService bus. Por último, el MB-EA (MicroBroker) enruta el evento a Premises. A continuación se muestra una figura para aclarar la conversión de formatos entre Premises y el DataCapture. Ilustración 14. Mapeo de mensajes del Premises y DataCapture Como se observa en la figura anterior, tanto el sourceid/targetid, como el eventtype y el value son mapeados del CBE-XML al objeto Java Dictionary Servicios de Premises 6.1 El WebSphere Premises Server 6.1 cuenta con los siguientes servicios que se muestran a continuación: Persistence Manager Página 67

76 o Lleva a cabo la persistencia de eventos en la Base de Datos y/o EPCIS 7. ALE Wrapper o Se mantiene a la escucha de las lecturas de tags y las coloca en el ALE AMiT Wrapper o Se mantiene a la escucha de los eventos del bus y los coloca en el AMiT. Output Channel o Escucha a los eventos, comprueba las plantillas para concordar con un topic determinado, y posteriormente lo reenvían a un canal de salida. Event Processors o Heartbeat, Alertas, lecturas de tag Los Event Processors son task agents que están vinculados en sus deployment descriptors a un nombre JNDI de un Activation Spec o Listeners. Los Activation Specs se usan cuando un task agent está a la escucha de un sistema de mensajería WAS como colas o topics en el SI-BUS. Los Listeners se usan cuando un task agent está a la escucha de un sistema externo de mensajería, como colas y topics MQ. Por último, los Activation Specs se vinculan a los topics y se definen en el WAS por la consola administrativa del WAS. 7 EPCIS: EPC Information Services (EPCIS) es un estándar de EPCglobal diseñado para permitir los datos relativos para compartir datos EPC (Electronic Product Code) entre distintas empresas del mismo o diferentes negocios. El objetivo de dicha compartición de datos es permitir a los participantes de la red EPCglobal contar con una visión común de la disposición de los objetos EPC en un contexto empresarial. Página 68

77 4.2. IBM Tivoli Maximo Asset Management Conceptos básicos Maximo application se refiere a una instancia de Maximo. Los Enterprise Application Archive (EAR) definen lo que constituye una Maximo application. Es posible contar con varias Maximo applications, lo que significa tener varios EAR s desplegados en un application server. Un EAR representa una aplicación Java 2 Enterprise Edition (J2EE) que es desplegada en un servidor de aplicaciones. Estos ficheros son archivos Java estándar y tienen la extensión.ear. Este tipo de archivos puede consistir en: Web Application Archive (WAR), que son ficheros que contienen por ejemplo, páginas JSP s o HTML. Java Enterprise Application (JAR), ficheros que contienen ficheros.class (ficheros objeto) y otros módulos de programación. Ficheros Enterprise Java Bean (EJB), que contienen ficheros class. IBM utiliza el término application server para referirse a un contenedor J2EE que proporciona la infraestructura para ejecutar aplicaciones empresariales como Maximo. IBM WebSphere es un servidor de aplicaciones comercial soportado por Maximo. Cuando instalamos Maximo, creamos un application server nuevo (en el sentido de contenedor) para la interacción de Maximo con el WAS. El contexto es el nombre a través de cual accedemos a una aplicación web específica, como Maximo, desplegada en un Application Server. Maximo tiene los contextos siguientes: /maximo Maximo user interface /mbo Maximo business objects /maximohelp Ayuda de Maximo /acweb Actuate /meaweb Maximo Enterprise Adapter Accederemos a Maximo desde el explorador web utilizando el contexto /maximo. Por ejemplo, name>:<port number>/máximo Página 69

78 4.2.2 Estructura de ejecución de Maximo En este apartado se mostrará cuál es la estructura de ejecución de Maximo en el Application Server. Los ficheros EAR son creados en los directorios configurados durante la instalación. Maximo consta de los ficheros EAR siguientes: maximo.ear Para la aplicación de Maximo. maximohelp.ear Para la ayuda de Maximo. acweb.ear Para la aplicación IBM Actuate Active Portal Integration Para ejecutar Maximo, es necesario desplegar los ficheros EAR en el Application Server. Cuando se despliegan los ficheros EAR en el Application Server, el servidor mantiene una copia de los EAR internamente. La instalación de Maximo construye los ficheros EAR basándose en la información que se proporciona en la instalación. Cualquier cambio de configuración requiere que se vuelvan a construir y a desplegar los ficheros EAR Estructura de la configuración de Maximo Se utilizará el application server para desplegar los ficheros EAR que el programa de instalación genera. Los tres ficheros EAR, maximo.ear, maximohelp.ear y acweb.ear, comprenden únicamente una aplicación Maximo (MAXIMOSERVER). Después de desplegar los ficheros EAR, una copia de cada fichero EAR es guardada en la estructura de carpetas del application server. El diagrama siguiente muestra el Application Server MAXIMOSERVER ejecutando Maximo en el servidor de aplicaciones IBM WebSphere en una única máquina física. Página 70

79 Ilustración 15. Estructura de Maximo Las aplicaciones de Maximo están basadas en la tecnología JSP. El Application Server, tal como el IBM WebSphere, se usa para aceptar HTTP request de los programas clientes (web browsers) y para responder con el contenido HTTP. Cuando un cliente solicita una página JSP, el servidor de aplicaciones procesa la página y el web server envía el resultado de la página al cliente. Por otro lado, Maximo utiliza ficheros XML para la renderización y creación de la interfaz de usuario Arquitectura de Maximo Asset Management Maximo es una plataforma de gestión de activos basada en una arquitectura Web y está formada por varios servidores Componentes de Maximo IBM Maximo consta de varios servidores software. Dependiendo del tamaño de la implantación, es recomendable instalar los servidores en la misma máquina física o bien en máquinas diferentes. Una implementación de Maximo consta básicamente de los tres servidores siguientes: Maximo Database Server Maximo Application Server Actuate Report Server Página 71

80 Application Server Maximo usa un Application Server para dar acceso a los componentes de negocio de Maximo y a la aplicación Web. MAXIMOSERVER es el nombre por defecto para el Application Server en el que Maximo está siendo ejecutado. Este servidor se crea durante la instalación. IBM Maximo está basado en tecnología J2EE, lo que requiere un servidor comercial de aplicaciones. Maximo puede utilizar tanto BEA WebLogic o el servidor de IBM, IBM WebSphere Application server. En estos servidores se ejecutan las aplicaciones de Maximo utilizando JSP's, XML y aplicaciones específicas de Maximo. Maximo agiliza la interfaz vía XML, permitiendo crear formatos de datos y compartir el formato y el dato. El código XML contiene tags que referencian cada control con el interfaz. Los valores del atributo son pasados a controles en cada XML tag, determinando la apariencia del control y su funcionamiento. El código XML se mapea en una base de datos, pero no como ficheros. Cuando se accede a una aplicación desde Maximo, el Application Server carga el XML de la base de datos. Posteriormente, dependiendo de los tags, el servidor de aplicaciones optimiza el código relativo a la interfaz que es enviado al cliente. Debido a que la base de datos almacena datos de la interfaz, cualquier texto localizable en ésta como etiquetas, mensajes y diálogos también son almacenados en la base de datos. Maximo también instala el Active Portal, que permite utilizar la web para acceder a informes de Maximo (Enciclopedia Volume) y a la Consola de Administración (Management Console). Esta funcionalidad basada en web permite desplegar y testear informes en el Enciclopedia volume. Cuando instalamos Maximo, se generar básicamente tres ficheros EAR: maximo.ear Para la aplicación de Maximo maximohelp.ear Para la ayuda acweb.ear Para el Actuate Active Portal Página 72

81 Ilustración 16. Ficheros ear de Maximo Los.ear son ficheros que contienen todos los archivos necesarios para ejecutar una aplicación. Maximo utiliza los tres.ear citados anteriormente. Cada uno de ellos contiene uno ó más módulos Web (extensiones.war): maximo.ear o maximouiweb.war o mboweb.war o meaweb.war maximohelp.ear o Maximohelp.war acweb.war o acweb.war Página 73

82 Fichero.war Descripción maximouiweb.war mboweb.war meaweb.war maximohelp.war acweb.ear Contiene la interfaz de Maximo, basada en JavaServer Pages (.jsp), clases Java, archivos HTML estáticos así como imágenes estáticas. El fichero buildmaximoear.xml contiene información acerca de de los ficheros de este módulo. Esta aplicación web utiliza los detalles de configuración de del fichero web.xml, ubicado en la carpeta <Maximo_root>\applications\Maximo\Maximouiweb\webmodule \WEB-INF. Este fichero también especifica la URL para acceder a la ayuda de Maximo Contiene los Maximo business objects (MBO) 8, clases Java tanto propias de Maximo como de terceros. El build.xml contiene información de todos los ficheros incluidos en este módulo. IBM Maximo Enterprise Adapter (MEA) permita a Maximo compartir datos con otros sistemas empresariales. Los usuarios crean y mantienen los datos en un sistema y el MEA se encarga de transferirlos a los demás, eliminando la tarea de duplicación. Proporciona las páginas de ayuda de Maximo. El fichero buildhelpear.xml contiene información acerca de todos los ficheros de este módulo. Es un Actuate Active Portal, empaquetado como acweb.war. El web.xml ubicado en <Maximo_root>\applications\activeportal\WEB_INF, contiene detalles de configuración del Actuate iserver. 8 Un MBO es una unidad functional de Maximo Application Server en el que se define un conjunto de campos y de reglas de negocio que pueden actualizar una ó mas tablas de Maximo. Página 74

83 Actuate Server El Actuate Informate Delivery Solution permite crear, gestionar y entregar informes. Es recomendable instalar el Actuate iserver en un servidor separado en la red para proporcionar: Un sistema para generar, gestionar y entregar informes interactivos en formato electrónico. Datos en múltiples formatos como DHTML, PDF, XLS Database Server IBM Maximo soporta (en la versión 6.2.1): IBM DB2 Universal Database Oracle (9i) ó (Estándar or Enterprise Edition) Microsoft SQL Server 2000, Service Pack Configuración Típica de Maximo A continuación, se muestra un esquema de la configuración típica de Maximo. Página 75

84 Ilustración 17. Configuración típica de Maximo En la Ilustración 17 se puede observar el esquema de configuración típica de Maximo. Se supone una máquina cliente, la que en la ilustración se denomina Workstation. Dicha máquina se conectará a dos servidores de aplicaciones (en el sentido lógico), uno el que se utiliza para albergar la aplicación de Maximo con sus correspondientes.ear, incluyendo bien IBM WebSphere o BEA Weblogic. Por otro lado, también se conectará al servidor de Actuate, basado en iserver, utilizado para la generación de informes. Tanto estos informes como los datos necesarios para el trabajo correcto de Maximo son albergados por un tercer servidor, esta vez de bases de datos, pudiendo ser bien Oracle como SQL Server, y, recientemente se ha añadido la posibilidad de DB2. A continuación, en el capítulo Error! No se encuentra el origen de la referencia. se hará mayor hincapié en las configuraciones de Maximo y en sus métricas bajo un punto de vista de hardware. Página 76

85 4.2.5 Maximo Enterprise Adapter Introducción Maximo Enterprise Adapter es un conjunto de aplicaciones y de puntos de integración predefinidos que nos ayudan a integrar Maximo con otras aplicaciones y crear flujos de datos entre Maximo y esas otras aplicaciones, entre las que se puede incluir incluso otro Maximo. Características Principales de Maximo Enterprise Adapter Las características principales de Maximo Enterprise Adapter son las siguientes: Aplicaciones para gestionar y crear puntos de integración. Una aplicación para crear reglas de procesado para la personalización de las interfaces. Soporte de múltiples modelos de integración utilizando HTTP, mensajería, interfaces de bases de datos y ficheros de texto planos. Interfaces de procesado en tiempo real, batch o iniciados por el usuario, tanto de entrada como de salida de Maximo. Posibilidad de personalización de los objetos de integración predefinidos. Posibilidad de transformación de datos usando plantillas XSL. Balanceo de carga y escalabilidad gracias al uso de múltiples colas. Soporte de entornos distribuidos, lo que ayuda al reparto de carga, y, por tanto, conlleva la disminución del tiempo no operacional Maximo Enterprise Adapter contiene un conjunto muy extenso de interfaces predefinidas por Maximo para permitir la integración con las aplicaciones internas del mismo. Todas las interfaces de Maximo Adapter son Web service por defecto. Los usuarios pueden crear nuevas interfaces y utilizarlas con Web services sin escribir código de forma muy sencilla. Características Principales de Maximo Adapter Las características principales de Maximo adapter son las siguientes: Existencia de un conjunto de puntos e interfaces de integración tanto de entrada como de salida Capacidad de crear ficheros XML o ficheros de texto plano para interfaces de salida Página 77

86 Capacidad de llevar a cabo cargas masivas de ficheros XML o ficheros de texto plano para interfaces de entrada Generación dinámica de XML para todos los los objetos de integración y para las interfaces de Maximo El concepto básico de la integración consiste en que los datos que se encuentren en un sistema, se pasen a otro. Por ejemplo, se parte del supuesto de que contamos con Maximo y otro sistema con el que se quiere integrar. También se desea que cuando un evento suceda en Maximo, como la aprobación de los requisitos de una compra (PR), que se envíe la PR al sistema externo, o que cuando un evento suceda en el sistema externo, como la aprobación de una orden de compra (PO), ésta se reciba en Maximo. Al primer escenario se le llama flujo de salida (outbound) mientras que al segundo, de entrada (inbound) Arquitectura Visión general La integración de Maximo facilita el intercambio de datos entre Maximo y aplicaciones externas, bien en tiempo real, o bien de tipo batch. Los datos son intercambiados vía Página 78

87 interfaces, cada una de ellas, actúa como un canal de comunicación entre el sistema externo y uno o más puntos de integración de Maximo Ilustración 18. Esquema de integración de Maximo El proceso de integración de Maximo se puede representar en tres capas, como se describe en la siguiente tabla: Capa de Integración Integration Object Layer Descripción Crea y gestiona los objetos y puntos de integración. Cada uno de ellos está compuesto por uno o más MBOs, que proporcionan el contenido necesario para un punto de integración específico. Los puntos de integración proporcionan un framework para acceder a los MBOs así como los métodos definidos en los MBOs Página 79

88 Interface Layer Crea y gestiona las interfaces, incluyendo las reglas de negocio así como los procesos de transformación de datos. Las interfaces implementan uno o más puntos de integración, independientemente de la dirección (inbound, outbound) y cada combinación de punto-interfaz de integración puede tener una clase de procesado, una clase de usuario ó reglas de procesado asociadas External System Layer Crea y gestiona los sistemas externos y sus interfaces. Esto incluye la definición de sistemas externos que intercambian datos con Maximo, identificando las interfaces específicas aplicables a cada sistema externo, independientemente de la dirección (inbound, outbound), configurando los valores de control de la interfaz (si es necesario) e identificando parámetros de colas para el sistema y el método de comunicación usado para enviar datos al sistema Adicionalmente a las tres capas, la integración incluye entidades específicas para la salida (outbound) y la entrada (inbound). Página 80

89 Ilustración 19. Arquitectura de la integración de Maximo Integration Object Layer El Integration Object Layer de Maximo interactúa con los Maximo Business Objects y facilita su creación y mantenimiento. Ilustración 20. Maximo Enterprise Adapter Integration Object Layer Página 81

90 Integration Objects Un Integration Object (Objeto de integración) consta de uno o más sub-registros (subrecords) que derivan su contenido desde un MBO particular. Un MBO es una unidad funcional del Maximo Application Server que define un conjunto de campos y de reglas de negocio para actualizar una o más tablas de la base de datos de Maximo. Cada sub-record contiene campos de un MBO específico. Cuando creamos un Integration Object, especificamos el/los MBO(s) cuyos campos hacen al objeto. Podemos modificar el integration object excluyendo campos innecesarios y añadiendo campos definidos por el usuario. El nombre de los sub-records es el mismo que el correspondiente MBO. MBOs y los sub-records son dos entidades distintas y es importante distinguirlas. Entidad MBO Sub-Record Descripción Los MBOs son objetos que Maximo utiliza directamente para actualizar la base de datos. Durante la integración hacia dentro (inbound), los MBOs son creados desde los sub-records. Durante la integración hacia fuera (outbound), son los MBOs quien crean los sub-records Es una copia de un MBO incluida en un objeto de integración. No tiene porqué incluir todos los campos del MBO original. Durante la integración hacia fuera (outbound), Maximo rellena los campos de los sub-records mediante los campos correspondientes en el MBO original. Un Objeto de integración (Integration Object) consta de uno o más sub-records Ejemplo Existe en Maximo un objeto de integración predefinido para las órdenes de compra, MXPO, que contiene sub-records que corresponden a MBOs, en el siguiente diagrama: Página 82

91 Ilustración 21. MXPO Integration Object Si existen múltiples sub-records para un integration object, deben existir relaciones padre-hijo entre los MBOs correspondientes. Estas relaciones se definen en el framework de los MBOs y son usadas para navegar entre los distintos MBOs involucrados para definir una entidad de negocio específica. Cada MBO tiene campos persistentes o no persistentes en su definición. Un campo persistente es aquel que mapea directamente una columna de una tabla de la base de datos de Maximo después de procesarlo, y un campo no persistente es aquel que es incluido en la definición del MBO pero no es almacenado en la base de datos, generalmente se suelen utilizar estos tipos de campos como campos temporales del MBO ya sea para cálculos, etc., por ejemplo, si tenemos dentro de un MBO un campo DESCRIPTION (persistente), es muy posible que también tengamos un campo DESCRIPTION_LONGDESCRIPTION en el cual se almacenaría parte de la descripción que no fuera posible almacenarla en el campo DESCRIPTION, a la hora de mapear la descripción del MBO en la base de datos se compondría la descripción entera y se mapearía. Por defecto, todos los campos persistentes son incluidos en el sub-record correspondiente en un integration object, y los no persistentes son excluidos. El usuario puede, opcionalmente, excluir campos persistentes e incluir campos nopersistentes. También es posible añadir campos definidos por el usuario para soportar algunos requerimientos. Página 83

92 Integration Points Un punto de integración (Integration Point), proporciona acceso a un objeto de integración (Integration Object) en una dirección dada (inbound u outbound). Los outbund integration points recogen los datos de los MBOs para construir el objeto de integración, mientras que los inbound integration points crean, actualizan o consultan a los MBOs, dependiendo de la operación asociada al punto. Un objeto de integración puede tener múltiples puntos de integración asociados con él, independientemente de la dirección. Propiedades Los Puntos de integración (Integration Points), tienen dos propiedades primarias, la dirección y la operación. La dirección indica el origen y el destino de la transacción que utiliza el punto, como se indica a continuación: Dirección Outbound Inbound Descripción La transacción se origina en Maximo y se envía a un sistema externo La transacción se origina en un sistema externo y es enviado a Maximo La propiedad de la operación indica el propósito del punto de integración. Algunas operaciones son únicamente permitidas en direcciones específicas: Operación Propósito Dirección Notify Query El punto de integración realiza una sincronización de datos El punto de integración realiza consultas/querys Ambas Inbound Response El punto de integración proporciona una respuesta a una query Outbound Página 84

93 Query and Response Integration Points Maximo proporciona un framework para sistemas externos tanto para hacer querys utilizando los objetos de integración, como para devolver la respuesta. Los puntos de integración de Querys pueden ser definidos únicamente en dirección de entrada (inbound), y las respuestas sólo en dirección de salida (outbound). Integration Point Processing Class Una clase de procesado de puntos de integración (Integration Point Processing Class) es una clase Java que proporciona acceso al objeto de integración correspondiente y a los MBOs asociados con ese objeto. Las clases de procesado actúan en conjunto con los MBOs para facilitar la transferencia de datos desde y hacia Maximo. Estas clases son opcionales, y un punto de integración puede o no tener clases de procesado asociadas con él. Los usuarios pueden crear clases de procesado personalizadas. Las clases de procesado hacia Maximo (Inbound integration point processing classes) son más comunes que las de desde Maximo (outbound). Generalmente filtran datos, llaman a métodos específicos en los MBOs o preprocesan los datos, y convierten los integration objects en los MBOs, que pueden ser procesados por Maximo. Los puntos de integración predefinidos de salida de Maximo (outbound integration points), generalmente no utilizan clases de procesado. Sin embargo, en casos en los que Maximo utiliza el mismo MBO para diferentes procesos de negocio o aplicaciones, un outbound integration point processing class filtra el dato desde el MBO para asegurarse de que sólo las transacciones relevantes son enviadas vía puntos de integración. Ejemplo El objeto de integración MXISSUE utiliza el MBO MATUSETRANS, que soporta cuestiones, devoluciones Desde que el punto de integración MXISSUEOUT envía simplemente la cuestión y devuelve la transacción, utiliza clases de procesado para filtrar directamente los destinos. Página 85

94 A continuación, se muestra una figura con los componentes de la integración Eventos de integración en tiempo real Durante la creación de un punto de integración saliente, un listener de eventos de integración es automáticamente registrado en el MBO primario del punto de integración. Cuando el listener es activado, monitoriza las actividades del correspondiente MBO Interface Layer La capa de interfaz de Maximo hace de intermediario entre los sistemas externos y los puntos de integración. Las interfaces permiten que diversos sistemas externos accedan a los puntos de integración de entrada, y a los puntos de integración de salida les permiten enviar datos a sistemas externos y aplicaciones. Página 86

95 Ilustración 22. Capa de interfaz de Maximo Enterprise Adapter Adapters Todas las interfaces se definen con un adapter, que no son más que un conjunto de interfaces, programas, mapeos y controles. Por defecto, todas las interfaces proporcionadas por Maximo son definidas dentro del Maximo adapter. Existen adapters ya configurados para la integración con aplicaciones comerciales como Oracle o SAP, aunque estos son de pago. Los usuarios pueden añadir nuevas interfaces a los adapters existentes o bien crear nuevos adapters, en caso de ser necesario. Los adapters pueden ser internos o externos, dependiendo del formato de datos de las interfaces dentro del adapter. Página 87

96 Adapters Internos Las interfaces que estén definidas dentro de adapters internos derivan su contenido directamente en los objetos de integración correspondientes, esto significa que deberán contar con el formato de datos de Maximo. El Maximo adapter proporcionado con Maximo Integration es un adapter interno. Por defecto, los nuevos adapters son creados como internos (internal type adapters). Adapters Externos Las interfaces definidas dentro de adapters externos utilizan un formato de datos diferente del usado por Maximo. El mapeo entre el formato externo y el formato de Maximo está hecho utilizando código Java u hojas de estilo XSL. Las interfaces definidas para los adapters externos no pueden utilizar las interface tables para procesar datos entre Maximo y el sistema externo, puesto que no se aplicaría el procesamiento XSL y por lo tanto, no se reconocería el mensaje recibido en Maximo, dando así un error. La definición de interfaces se puede observar de manera visual en la figura que se muestra a continuación Página 88

97 Interfaces Maximo utiliza interfaces para transformar datos desde el formato de Maximo a un formato externo y viceversa; y para llevar a cabo reglas de negocio adicionales a los datos. La interfaz es lo que el sistema externo ve de Maximo. Por ejemplo, Maximo puede necesitar enviar una transacción relacionada con una cuenta a una aplicación de contabilidad, requisitos de compra a una aplicación de compras, etc. Si cada sistema externo utiliza reglas de negocio diferentes o formatos de datos diferentes, no sería posible enviar las transacciones en el formato de Maximo, por lo que entonces las interfaces específicas para estas aplicaciones procesan las transacciones acorde con el formato y los requisitos de procesado de cada sistema externo. Maximo proporciona interfaces predefinidas de aplicaciones específicas. Si un objeto de integración es específico para una interfaz, restringe los puntos de integración que pueden ser asociados con la interfaz: Página 89

98 Un objeto de integración debe ser definido para una interfaz dentro de un internal type adapter. Estas interfaces utilizan la definición del objeto de integración asociado con la interfaz. Los objetos de integración no pueden ser especificados a interfaces dentro de un adapter externo. El formato de la interface no está basado en un objeto de integración. Es posible usar una clase Java o una hoja de estilo XSL para crear el formato necesario. Propiedades de las interfaces Al igual que los puntos de integración, cada interfaz tiene una propiedad de operación (Notify, Query, Response), que indica el propósito de la interfaz. Es necesario especificar la operación de la interfaz antes de que los puntos de integración sean asociados con la misma. La operación especificada para la interfaz restringe los puntos de integración que pueden ser asociados con ella. Solamente los puntos de integración con la misma propiedad pueden ser asociados con una interfaz; esto es, interfaces de tipo query solamente pueden ser asociadas con puntos de integración de tipo query; y los interfaces tipo response con puntos de integración de tipo response. Estas interfaces hacen visibles los integration points de un integration object y permiten a los usuarios hacer querys a Maximo para consultar datos utilizando documentos XML. Página 90

99 Ilustración 23. Ejemplo de formato de integración Query and Response Type Interfaces Las operaciones de tipo Query y Response están disponibles sólo para interfaces definidas en el Maximo adapter y sólo se pueden acceder a ellas vía Maximo Web services. Página 91

100 Formatos de datos Maximo y los sistemas externos pueden intercambiar transacciones de datos vía mensajes XML, tablas o ficheros de texto planos. Maximo utiliza XML y tablas para transacciones en tiempo real y ficheros de texto planos para importación o exportación masiva de datos. Maximo XML es la representación XML que los MBOs reconocen. Maximo escribe todos los mensajes de salida XML en este formato y requiere que los mensajes de entrada que no sean Maximo XML sean convertidos a este formato. Si un sistema externo utiliza otro formato XML, hay que transformarlo, vía Java o XSL style sheets. Las Interface Tables son tablas de bases de datos relacionales que se pueden usar en vez de mensajes XML para transferir datos entre Maximo y sistemas externos. Cada tabla contiene los mismos campos de datos que el correspondiente Maximo XML interfaz en formato plano Los Flat files o ficheros de texto planos, es una representación no relacional, no jerárquica de las columnas de datos en una tabla de Maximo. Los ficheros de texto Página 92

101 plano son usados para hacer la carga inicial de datos en Maximo, y para llevar a cabo importaciones o exportaciones periódicas de datos. Conversión de datos En las interfaces predefinidas, la conversión de datos se lleva a cabo en la clase de procesado del punto de integración asociado con la interfaz. Los usuarios pueden sobrescribir o suplementar este código escribiendo una clase de usuario o con una hoja de estilo XSL y asociándolas con la combinación de interface-punto de integración. Todas las interfaces definidas en adaptadores de tipo externos utilizan formatos de datos diferentes de los usados en Maximo, es por ello por lo que se requiere una clase de usuario o una hoja de estilo XSL para llevar a cabo la conversión entre el formato de Maximo y el formato externo. Página 93

102 Reglas de procesado de las interfaces Las reglas de procesado de las interfaces permiten a los usuarios cambiar el comportamiento de cualquier interfaz sin tener que escribir ninguna clase Java. Las reglas de procesado pueden acceder y evaluar valores en XML y en campos de los MBOs, conjuntos de MBOs y cambiar los valores en los campos del XML o del MBO, o parar el procesado de la transacción. Las reglas de procesado se pueden aplicar a cualquier interfaz, independientemente del adaptador en el que la interfaz fue creado. Sin embargo, los datos referenciados por una regla deben estar en el formato de Maximo, por lo que los usuarios deben primero transformar cualquier dato Controles de las interfaces Los controles de las interfaces proporcionan a los usuarios la capacidad de modificar el comportamiento de ciertas interfaces y configurar interfaces dependiendo de los requisitos individuales. Las reglas de procesado pueden acceder a controles de la interfaz y a clases Java. Cada adapter tiene su propio conjunto de controles, que están asociados con las interfaces dentro de ese adapter. Cada sistema externo que usa el adapter tiene una copia configurable de los controles. Dos sistemas externos que procesan la misma interfaz pueden compartir la misma lógica de procesado. Maximo proporciona cuatro tipos de controles de interfaz: 1. Boolean: Especifica un valor de 0 (false) ó 1 (true) 2. Cross-reference: Reemplaza un valor con otro 3. List: Especifica una lista de valores 4. Value: Especifica un valor simple Página 94

103 Capa de sistemas externos (External System Layer) Cualquier aplicación que envía datos a Maximo o recibe datos de Maximo es considerado un sistema externo. La External System Layer permite el flujo de datos entre Maximo y los sistemas externos definiendo la ubicación y las características de los sistemas externos, e identificando los adapters y las interfaces que cada sistema externo utiliza. Ilustración 24. Maximo Enterprise Adapter External System Layer Definición y configuración de sistemas externos Un sistema externo interactúa con Maximo, como un punto final (location) al cual Maximo envía información o como una fuente desde el cual Maximo recibe datos de entrada. Un sistema externo puede utilizar interfaces de entrada, de salida o una combinación de ambas. Maximo puede ser integrado con cualquier número de sistemas externos. Cada Página 95

104 sistema externo utiliza un adapter para intercambiar mensajes con Maximo en el formato identificado por el adapter. Ilustración 25. Maximo Enterprise Adapter External System Structure El nombre dado al sistema externo es por el cual Maximo lo reconoce. Los mensajes XML de entrada y las transacciones de tablas deben especificar este nombre en el campo SenderID, y Maximo escribe este nombre en el campo RecipientID de los mensajes de salida XML y las tablas de interfaz. En las transacciones de salida, el SenderID es el valor de MAXVARS.MXSYSID. El Maximo adapter proporciona un sistema externo predefinido, EXTSYS Valores de control de las interfaces (Interface Control Values) Cuando especificamos un adapter para un sistema externo, Maximo incluye en este sistema todos los controles definidos para el adapter correspondiente. Es posible modificar los valores por defecto de los controles o añadir nuevos valores si procede Destinos (End Points) Un End point es una ubicación a la cual la cola de salida envía los datos. Los end points son independientes de los adapters y los sistemas externos, aunque dos sistemas que utilizan diferentes adapters suelen tener diferentes destinos. Típicamente, un end-point tiene componentes de aplicación que procesa los datos enviados desde Maximo. Página 96

105 Los sistemas externos pueden asociearse con end points de muchas formas, el uso exacto depende de la implementación. Posibles escenarios pueden ser (aunque no están limitados), los siguientes: Un end point único por un sistema externo Este es el escenario más común en una arquitectura punto a punto, donde cada sistema externo tiene diferente destino Un end point único que soporta varios sistemas externos Varios sistemas externos utilizan el mismo conjunto de tablas o comparten una única cola. En este caso se configura Maximo para usar el mismo end point, y el end point contendrá múltiples instancias de los mensajes de salida (una por cada sistema externo) Cada end point se asocia a un handler, que es una clase de procesado que define cómo y en qué formato, Maximo envía datos desde la cola de salida al end point. Maximo proporciona los siguientes end points. Es posible crear nuevos en caso de ser necesario. End Point MXFLATFILE Descripción Escribe datos en un archivo de texto plano, en forma de tabla, en un directorio predefinido MXIFACETABLE Escribe los datos en una tabla (en una base de datos relacional) en un directorio predefinido MXXMLFILE Escribe datos en formato XML Colas de entrada y salida (Inbound and Outbound Queues) Una cola es un servicio de mensajería Java (JMS), que Maximo utiliza durante el intercambio de mensajes entre Maximo y los sistemas externos. La funcionalidad JMS está disponible en los servidores de aplicaciones BEA WebLogic e IBM WebSphere Maximo utiliza una cola de salida y dos de entrada. Las colas de entrada son utilizadas por el Maximo Integration Gateway para dejar los mensajes de entrada asíncronos para su posterior Página 97

106 procesamiento por Maximo. Las colas de entrada se diferencian entre sí en la forma de gestión de errores: La cola secuencial de entrada procesa las transacciones en orden FIFO, y deja de procesar cuando encuentra un error en una transacción. Es recomendable usar esta cola para procesar interfaces que dependan de otras interfaces que deben correctamente La cola continua de entrada no procesa en orden FIFO y continúa procesando las transacciones aunque encuentre un error. Es recomendable usar esta cola para cargar datos que no dependan del estado de finalización de otras interfaces. Es posible utilizar para un sistema externo la cola secuencial para unas interfaces y la continua para otra, o también es posible usar una cola para todas las interfaces de entrada. Maximo tiene predefinidas las siguientes colas. Es posible crear colas adicionales si fuese necesario. cqin: Continuous inbound (Entrada continua) sqin: Sequential inbound (Entrada secuencial) sqout: Sequential outbound (Salida secuencial) Comunicación de entrada y salida En esta sección se mostrará la forma en el que se pueden enviar transacciones o recibirlas, de los sistemas externos. Ilustración 26. Maximo Enterprise Adapter Inbound and Outbound Communication El esquema general para la integración es el que se muestra a continuación. Página 98

107 Inbound Gateway Communication El Maximo integration Gateway suministra un framework para recibir y encolar transacciones XML de un sistema externo. El Gateway procesa las transacciones recibidas vía JavaBeans (EJB), HTTP/HTTPS y web service. Determina si Maximo debe procesar el mensaje, escribe el mensaje en la cola de entrada y notifica al sistema externo cuando el mensaje se ha procesado correctamente Outbound Handler Communication Maximo manda datos desde la cola de salida a un destino (end point) por medio de un handler, que es una clase que define cómo y en qué formato los datos han de ser entregados. La mayoría de los handlers utilizan un conjunto de propiedades, como una URL específica, un usuario y una contraseña, o un directorio específico. Los valores de estas propiedades dependen del end point asociado con el handler. Maximo tiene predefinido los siguientes handlers. Es posible crear nuevos si fuesen necesarios. EJB: Entrega datos de salida a Enterprise JavaBeans, que se ejecutan bien en el servidor local o en el remoto FLATFILE: Introduce los datos de salida en un fichero de texto plano cuya ubicación es configurable Página 99

108 HTTP: Entrega los datos de salida como un documento XML vía HTTP ó HTTPS IFACETABLE: Entrega los datos a una tabla de una base de datos relacional JMS: Entrega los datos en un sistema de colas que ha sido activado vía Java Message Service (JMS) WEBSERVICE: Entrega los datos a Maximo Web services usando SOAP vía HTTP XMLFILE: Entrega los datos en formato XML en un fichero de la máquina local o una carpeta compartida Comunicación de Salida Maximo es capaz de procesar dos tipos de integración de salida: En tiempo real, iniciado por las entradas de datos en Maximo Tipo Batch, iniciado por la función de exportar datos en Maximo. A continuación se muestra un esquema de las distintas formas que Maximo tiene de llevar a cabo esta comunicación Inicio de la comunicación de salida Un usuario de Maximo inicia el proceso de integración de salida. Esto puede ser bien un proceso que corre en segundo plano que es iniciado cuando un usuario completa una Página 100

109 transacción en Maximo (procesado en tiempo real), o el inicio de la opción de exportar datos desde la aplicación Sistema Externo (procesado batch). La opción de exportar datos permite exportar el resultado de una Query desde Maximo a un sistema externo. Típicamente utiliza diferentes interfaces que son usadas para la integración en tiempo real. Algunas interfaces de procesado en tiempo real implican el cambio de algunos valores o la parada del usuario de llevar a cabo una actividad. Ninguna de estas actividades son aplicables en el modo Exportar Datos Integración en tiempo real 1. El usuario completa una transacción en Maximo. Este es el único punto visible para el usuario en la integración hacia fuera en tiempo real. 2. El MBO primario asociado con la transacción identifica el punto de integración relacionado que tiene el listener activado 9. El proceso de integración de salida es iniciado para todos aquellos puntos de integración con los listeners activados Integración Batch 1. En la aplicación Sistemas Externos, el usuario selecciona el sistema externo al cual los datos serán enviados. 2. En la pestaña Outbound Interfaces, el usuario selecciona una interface, y posteriormente selecciona la opción Exportar Datos (Data Export) 9 Nota: Para comprobar si un event listener está activado para un punto de integración en particular, ir a Enable/Disable Integration Events en el menú de Seleccionar Acción en la aplicación de Sistemas Externos. Página 101

110 3. El usuario selecciona los registros a ser exportados creando una Query que puede ser creada por el mecanismo de Maximo query-by-example (QBE). La query debe actuar en el MBO primario en el integration object Si la query devuelve un result set válido, el proceso de exportar datos continúa Construyendo el Integration Object El framework de integración construye un integration object desde el MBO. 1. El integration object asociado con cada punto de integración se resuelve. 2. El integration object identifica su(s) MBO(s) 3. El framework de integración construye el integration object desde los MBOs 4. El framework de integración añade la siguiente información de cabecera al integration object: 10 Para comprobar el nombre del MBO primario de un integration object, revisar en la pestaña Integration Object en la aplicación Integration Objects. Si el check-box Merged Object? En la parte superior derecha de la ventana no está seleccionada, el primer MBO en la tabla que se muestra en la ventana es el MBO primario. Si el checkbox Merged Object? está seleccionado, no es posible exportar esta interface. Página 102

111 La salida de esta actividad es un integration object con el siguiente formato y cabeceras: <Integration Object Name> <Header> <SenderID>Value of MAXVAR.MXSYSID</SenderID> </MessageID> <CreationDateTime>System DateTime </CreationDateTime> </RecipientID> </Header> <Content> <IntegrationObject>... </IntegrationObject> </Content> </Integration Object Name> Aplicando el proceso de integración object. El framework de integración aplica lógica de procesado (si se especifica) al integration Página 103

112 Las clases de procesado predefinidas del integration point verifican y filtran los integration objects, para asegurar que su contenido concuerda con la definición del punto de integración. Estas clases predefinidas no cambian ni editan los datos en el integration object. No todos los integration points tienen una clase de procesado. 11 Las siguientes posibilidades se pueden dar: Duplicando el Integration Object Si el integration point está asociado con múltiples interfaces o sistemas externos, el framework de integración crea copias del Integration Object. 11 Para comprobar si una clase de integración está asociado con un punto de integración, mirar en la pestaña Integration Point en la aplicación Integration Objects. Página 104

113 1. El framework de integración crea una copia del Integration Object para cada combinación de interface y sistema externo asociado con el punto de integración. 2. El framework de integración actualiza la información de cabecera en cada integration object, como sigue El resultado de esta actividad es un integration object por combinación de interface y sistema externo, con el siguiente formato y cabecera: <Integration Object Name> <Header> <SenderID>Value of MAXVAR.MXSYSID</SenderID> <MessageID> MessageID per external system outbound interface</messageid> <CreationDateTime>System DateTime </CreationDateTime> <RecipientID>External System Name</Recipient> </Header> <Content> <IntegrationObject>... </IntegrationObject> </Content> </Integration Object Name> Desde este punto, las acciones listada en cada paso, se aplican a cada copia del integration object que es creado en el paso anterior, para una combinación específica sistema externo-interface. Si el procesado de salida para un sistema externo-interface determina que un integration object duplicado debería ser omitido debido a datos inapropiados, la acción de omitir aplica sólo a esa copia del integration object; esto es, a aquella combinación específica sistema externo-interface. Si el procesado determina que un integration object duplicado debería ser parado debido a un error en los datos, la acción de parar se aplica a todas las copias del integration object creadas en este paso. Página 105

114 Aplicando reglas de procesado de las interfaces de integración. El framework de integración aplica las reglas de procesado (si corresponde) al objeto Las reglas de procesado de las interfaces definen las condiciones en las cuales Maximo puede omitir o parar una transacción, o cambiar los datos en un integration object. Si alguna existe, el framework de integración las aplica a los integration objects en el orden especificado por el número de secuencia de la regla de procesado 12. Los posibles resultados de esta tarea pueden ser los siguientes: Aplicando Preprocesado de usuario El framework de integración aplica lógica de procesado definida por el usuario (si corresponde) al integration object. 12 Para comprobar si existe regla de procesado para un integration object, consultar en la pestaña Outbound Processing Rules en la aplicación Integration Interfaces. Página 106

115 Un método de procesado es una clase de usuario que permite manipulación de integration object antes de que el procesamiento predefinido tenga lugar en la interface. Los usuarios típicamente utilizan esta funcionalidad para personalizar las interfaces predefinidas. Los adapters predefinidos no proporcionan ninguna clase de usuario 13. Los posibles resultados de esta etapa son: Aplicando el procesado de la interface El framework de integración aplica la lógica predefinida en el procesamiento de interfaces de la clase de procesado (si corresponde) al integration object. 13 Para comprobar si existe una personalización de preprocesado, revisar la pestaña Interface dentro de la aplicación Integration Interfaces. Si la subpestaña Outbound Integration Points muestra una clase de usuario, comprobar esa clase para un método de preprocesado. Página 107

116 Una clase de procesado de interfaces implementa típicamente lógica de procesado adicional y convierte datos desde los objetos de integración a formato de interfaces. El Maximo adapter no proporciona clases de procesado de interfaces predefinidas. El formato XML para las interfaces definidas en el Maximo Adatper es comparable al formato del integration object, donde el mapeo XML no tiene lugar. El resultado de esta etapa puede ser el siguiente: Aplicando post-procesado de usuario El framework de integración aplica lógica de procesado personalizada en la clase de usuario de salida (si corresponde) a la interface creada en la etapa anterior. Página 108

117 Esta opción se utiliza típicamente para personalizar una interface predefinida después de que el procesamiento de interface tenga lugar. Tanto el integration object como la interface creada de ese integration object están disponibles en este punto. Los adapters predefinidos no proporcionan clases de salida de usuario. Los posibles resultados del proceso son los siguientes: Aplicando el mapeo XSL El framework de integración aplica mapeos a las interfaces. Página 109

118 El mapeo XSL 14 permite a los usuarios mapear interfaces definidas por el usuario para personalizar clases de procesado de interfaces. Tanto el integration object como la interface están disponibles en este punto. La salida de esta actividad es un mensaje XML en el formato de una interface Enviando la Interface al sistema externo El framework de integración escribe la interface a la cola de salida, posteriormente se envía al sistema externo. 1. El integration framework escribe el mensaje XML a la cola de salida especificada por el sistema externo 14 Para comprobar si existe un mapeo XSL para una interface, ir a la pestaña Interface dentro de la aplicación Integration Interfaces. Mirar en la sub-pestaña Outbound Integration Points para un mapeo XSL. Página 110

119 2. La cron task que escucha a la cola de salida recoge el mensaje. 3. La cron task le pasa el mensaje al message router. El router utiliza el end point asociado con el sistema externo para identificar el handler correcto. 4. La clase de procesado asociada con el handler envía los datos al sistema externo Comunicación de entrada Maximo lleva a cabo dos tipos de integración de entrada: Basado en colas, iniciado vía interface tables, el integration Gateway o la opción Importar datos de Maximo. Síncrono, iniciado vía Maximo Web services La sincronización de interfaces (operation = Notify) puede ser procesada de forma síncrona o vía la cola. Las interfaces de Query y Responde pueden ser únicamente procesadas síncronamente (vía Maximo Web services). Como en el caso anterior, se muestra a continuación un esquema de esta comunicación. Página 111

120 La siguiente lista es una visión general de las actividades de procesado de entrada. No todas las actividades aplican a todas las transacciones de entrada. Los diagramas de las páginas siguientes lo muestran con un formato visual. Inicio del proceso de integración de entrada Escritura de mensajes en las colas de entrada Obtención de los mensajes de las colas de entrada Identificar los puntos de integración Aplicar el pre procesado de usuario Aplicar el procesado de clases de interface Aplicar el procesado de usuario Aplicar el mapeo XSL Duplicar el integration object Aplicar las reglas de procesado del Integration Object Construir los MBOs Aplicar las reglas de procesado de los MBOs Aplicar la clase de procesado del Integration Point Aplicar la el procesado de usuario de los MBOs Aplicar el procesado del MBO Inicio del proceso de integración Cualquier sistema externo puede enviar mensajes asíncronos de cualquiera de las siguientes formas: Página 112

121 Escritura de mensajes en las colas de entrada Los siguientes pasos describen la iniciación del procesamiento de entrada vía integration gateway: 1. El sistema externo deja un mensaje al integration gateway vía XML por HTTP o una llamada EJB. El mensaje puede encontrarse en cualquier formato XML. 2. La capa de intérprete del adapter identifica al remitente (sistema externo) y el nombre de la interface del mensaje. 3. El integration framework verifica lo siguiente: a. El sistema externo es válido y está activo b. La interface es válida y está activada para el sistema. Si la verificación falla, el integration framework notifica al remitente del error y no procesa el mensaje. 4. Si la verificación es correcta, el integration gateway identifica la cola JMS de entrada asignada a la interface seleccionada y el sistema externo. 5. El integration gateway escribe el mensaje en la cola de entrada. Si el mensaje contiene múltiples instancias de documentos (por ejemplo, si un mensaje simple contiene diez órdenes de compra), la aplicación escribe el mensaje único, no diez mensajes individuales a la cola. 6. El Integration framework actualiza la cabecera del mensaje con el sistema externo y los nombres del interface. Los siguientes puntos describen el comienzo del proceso de integración de datos de entrada vía opción de Importar Datos. NOTA: Esta opción sólo está disponible para sistemas externos que usan un internal adapter. Página 113

122 1. Un usuario selecciona la acción Data Import desde el menú Select Action en la aplicación Sistemas Externos. 2. El usuario identifica el tipo (XML o fichero de texto plano), el delimitador y la ubicación del fichero a ser importado a Maximo. 3. El adapter identifica el remitente (sistema externo) y el nombre de la interface del mensaje. 4. El integration framework verifica lo siguiente: a. El sistema externo es válido y está activo b. La interface es válida y está activada para el sistema. Si la verificación falla, el integration framework notifica al remitente del error y no procesa el mensaje. 5. Si la verificación es correcta, el integration gateway identifica la cola JMS de entrada asignada a la interface seleccionada y el sistema externo. 6. El integration gateway escribe el mensaje en la cola de entrada. Si el mensaje contiene múltiples instancias de documentos (por ejemplo, si un mensaje simple contiene diez órdenes de compra), la aplicación escribe el mensaje único, no diez mensajes individuales a la cola. 7. El Integration framework actualiza la cabecera del mensaje con el sistema externo y los nombres del interface. Los siguientes puntos describen la inicialización del proceso de integración vía interface tables. NOTA: Esta opción está disponible únicamente para sistemas externos que utilicen un internal type adapter. 1. El sistema externo escribe datos de la transacción a las interface tables apropiadas y actualiza la tabla MXIN_INTER_TRANS con la información relativa a la secuencia en la cual Maximo debería procesar los registros de la tabla. 2. Una cron task de Maximo regularmente comprueba la tabla MXIN_INTER_TRANS para comprobar registros a ser procesados. 3. Si existe algún registro preparado para ser procesado, el adapter identifica el remitente (sistema externo) y el nombre de la interface desde la tabla MXIN_INTER_TRANS. 4. El integration framework verifica lo siguiente: a. El sistema externo es válido y está activo b. La interface es válida y está activada para el sistema. Si la verificación falla, el integration framework notifica al remitente del error y no procesa el mensaje. Página 114

123 5. Si la verificación es correcta, el integration gateway identifica la cola JMS de entrada asignada a la interface seleccionada y el sistema externo Obtención de los mensajes de las colas de entrada El integration framework obtiene los mensajes de las colas de entrada Los usuarios pueden elegir procesar los mensajes desde la secuencial, o bien desde una cola continua, o una combinación de ambas. La cola secuencial procesa los mensajes en un orden FIFO estricto, mientras que la continua soporta procesamiento multi-hilo de transacciones. Cuando se da un error mientras se procesa un mensaje en una cola secuencial, la aplicación envía un al administrador del sistema, marca el mensaje como un error y para de procesar más mensajes hasta que el error sea corregido. Cuando ocurre un error mientras se procesa el mensaje en la cola continua, la aplicación envía un al administrador del sistema, marca el mensaje como un error y continúa procesando los mensajes siguientes de la cola. En este punto, los mensajes de entrada que fueron recibidos en la cola desde las interface tables o desde la carga de ficheros son convertidos al formato de Maximo XML. Esto aplica a mensajes provenientes de sistemas externos que utilizan el Maximo adapter o cualquier tipo de internal adapter. Página 115

124 El mensaje permanece en la cola de entrada hasta que se procesa entero por el integration framework. Una vez que el proceso ya está completo, la transacción es borrada de la cola. La salida de esta actividad es un mensaje XML en el formato de la interface Identificar los puntos de integración El framework de integración identifica el punto(s) de integración asociado(s) con el interface y crea una copia del mensaje (interface) para cada punto de integración. Las siguientes actividades identifican el punto de integración del mensaje: 1. El framework de integración recoge el registro de la cola de entrada. 2. Se identifica el adapter usado por el sistema externo. 3. La definición de la interface en el adapter lista los puntos de integración de entrada a los cuales la interface está mapeada. 4. El framework de integración crea una copia de la interface para cada punto de integración que está asociado con la interface. Si el framework de integración crea copias de la interface, el resultado del procesamiento se aplica a cada copia de la interface. La salida de esta actividad es una copia de la interface por cada punto de integración Pre-procesado de lógica de usuario El framework de integración aplica un pre-procesado de lógica de usuario (si corresponde) a la interface. Página 116

125 Un método de pre-procesado es una clase que permite la manipulación de una interface antes de que tenga lugar el procesamiento predefinido por Maximo. Los usuarios usan esta funcionalidad típicamente para personalizar interfaces predefinidas. Los adapters predefinidos no proporcionan ninguna clase de usuario. Las posibles salidas de este proceso son las siguientes: Procesamiento de las interfaces El integration framework aplica la lógica de procesado de las interfaces (si corresponde) a la interface. Página 117

126 El Maximo adapter no proporciona ningún tipo de procesado de interfaces. Implementa todas sus reglas de integración vía procesado de integration points y reglas de procesado. En general, los adapters utilizan el interface processing class para los siguientes propósitos: Para aplicar reglas de negocio específicas que no pueden ser especificadas utilizando las reglas de procesado. Para convertir datos de entrada desde el formato de una interface al formato de un integration object. Las posibles salidas de este proceso son las siguientes: Post-procesado de usuario El integration framework aplica la lógica de procesado contenida en las clases de usuario (si corresponde) a la salida de la actividad anterior. Página 118

127 Una clase de usuario personaliza típicamente el integration object después de la ejecución de la lógica predefinida de las interfaces. Tanto el integration object como la interface están disponibles en este punto. Maximo adapter no proporciona clases de usuario predefinidas. Las posibles salidas de este proceso son las siguientes: Mapeo XSL El integration framework aplica los mapeos correspondientes a la interface, para convertirlos al formato del integration object. Página 119

128 Las posibles salidas de esta etapa son las siguientes: Duplicar el Integration Object Si la transacción aplica a múltiples organizaciones o sitios, el integration framework crea una copia del integration object para cada organización o sitio. En la mayoría de los casos, una transacción sólo se relaciona con una organización o sitio. Sin embargo, en casos en los que la transacción aplica a múltiples organizaciones o sitios, Maximo (bajo un control de multiplicación) crea una copia de los integration objects para cada organización o sitio aplicable. Página 120

129 Por ejemplo, si queremos insertar un vendedor desde un sistema externo a Maximo dentro de múltiples organizaciones en vez de enviar el vendedor desde el sistema externo varias veces, se puede enviar únicamente una vez y se copiará a cada organización. Maximo Adapter no proporciona ningún control de multiplicación predefinido. La salida de esta actividad es un objeto de integración para cada organización o sitio especificado en el multiplication control Aplicar reglas de procesado de los Integration Objects El integration framework aplica reglas de procesado al integration object, antes de que los MBOs sean construidos Las reglas de procesado de los integration objects definen condiciones en las que Maximo puede omitir o parar una transacción, o bien cambiar datos en el integration object, anteriormente a la creación de los MBOs. Esta es la última oportunidad para modificar los campos clave definidos para el MBO. Las posibles salidas de esta actividad son las siguientes: Página 121

130 Construcción del MBO object. El integration framework construye el MBO(s) usando la información del integration La salida de esta actividad es el(los) MBO(s) Aplicar las reglas de procesado de los MBO(s) El integration framework aplica las reglas de procesado (si aplica) a los MBOs construidos, antes de guardarlos. Página 122

131 Las reglas de procesado permiten manipular los datos en los MBOs, antes de que los MBOs sean guardados. Es posible también utilizar las reglas de procesado para acceder y conseguir datos pertinentes de los MBOs que no estén incluidos en el integration object. Las posibilidades de salida de esta actividad son las siguientes: Procesado de los integration points El integration framework aplica la lógica predefinida al integration point. Página 123

132 Las posibles salidas de esta actividad son las siguientes: Procesado de lógica de usuario de los MBOs El integration framework aplica la lógica de procesado personalizada al MBO. Página 124

133 Las posibles salidas de esta tarea son las siguientes: Procesamiento del MBO El MBO se pasa a Maximo y se le aplica el procesado estándar de Maximo. NOTA: La integración de Maximo trata los mensajes únicos provenientes de la cola de entrada como una transacción simple de Maximo. Si el mensaje original da lugar a múltiples integration objects, Maximo debe procesar correctamente todos los MBOs creados a partir de todos los integration objects provenientes del mensaje antes de que se produzca un commit en la base de datos. Un error en cualquiera de los integration objects causará el fallo global de la transacción Integration Gateway El Integration Gateway proporciona el framework para recibir transacciones XML desde un sistema externo y escribirlas en las colas de entrada. El gateway procesa las transacciones recibidas vía HTTP/HTTPS, web services y Enterprise JavaBeans (EJBs). El Integration Gateway no se ve involucrado en las transacciones recibidas vía interface tables y ficheros planos de texto (usando la opción Importar datos), así como sincronización de datos y querys usadas vía Web services. A continuación se describe la llegada de las transacciones XML vía integration gateway y la función de la capa de la interpretación de los datos del gateway. Página 125

134 Gateway Framework El Gateway Framework proporciona los puntos de entrada a través de los cuales los sistemas externos pueden hacer llegar transacciones a Maximo. A bajo nivel, el gateway es un Enterprise JavaBean (EJB), que proporciona los siguientes servicios: Remote Method Invocation (RMI) Enterprise JavaBeans (EJB) Java Naming and Directory Interface (JNDI) El EJB puede ser también expuesto como una llamada a un procedimiento remoto (RPC) basado en web service, brindando así soporte SOAP. Ilustración 27. Componentes del Gateway Framework Existen dos formas de invocar al gateway EJB. Una implica una interpretación y la otra no Interpretation Layer Antes de que el gateway escriba una transacción a una cola de entrada, debe obtener y validar los nombres de las interfaces y los sistemas externos en los cuales la transacción se originó. Estas propiedades están incluidas en la cabecera del mensaje JMS que el gateway escribe en la cola. La interpretación es el proceso de parsear un documento XML para obtener información que Maximo necesita para procesar el documento. Si estos valores son consistentes en el XML con todas las interfaces, o si es posible proporcionar un valor fijo para cada propiedad, se define la ubicación de estas propiedades en la pestaña Gateway Properties. En caso contrario, es necesario escribir un intérprete nuevo que pueda identificar el remitente y el nombre de las interfaces. Si fuese así, la definición del intérprete se hace definiendo la clase, pero no las propiedades en la pestaña de Gateway Página 126

135 Properties. Para incluir datos adicionales en la cabecera del mensaje, hay que definir los datos como una de las propiedades dentro del diálogo Add/Modify Adapters. El Maximo adapter utiliza las dos propiedades que se muestran a continuación: INTERFACE (el nombre de la interface), derivado del elemento raíz (el tag de más alto nivel) en el mensaje XML. SENDER (el nombre del sistema externo), derivado del tag SenderID. Cuando definimos las propiedades del gateway, Maximo interpreta sus valores como sigue: Si seleccionamos el check box XML Tag? y dejamos el campo valor con un valor nulo, el gateway utiliza el nombre del elemento raíz del mensaje XML como el valor de la propiedad correspondiente Si seleccionamos el check box XML Tag? e introducimos un nombre en el campo valor, el gateway utilizará el valor para ese tag como el valor para la propiedad correspondiente. Si el tag aparece varias veces en el mensaje XML, el adapter utilizará el valor de la primera ocurrencia del tag. Si dejamos en blanco el check box XML Tag? e introducimos un nombre en el campo valor, el gateway utiliza estos datos como el valor de la propiedad correspondiente. Por ejemplo, Si no definimos un valor para la propiedad INTERFACE, y el tag de más alto nivel del mensaje XML es <MxItemInterface>, el Gateway utiliza MXItemInterface como el valor de la propiedad INTERFACE Envío de transacciones vía EJB La invocación de EJB puede ser hecha por clientes J2EE escritos con la especificación de Sun Microsistems, Inc. La invocación puede ser hecha con o sin los nombres de la interface y del remitente. Para invocar el EJB sin los nombres de las interfaces y del remitente, se utiliza el siguiente método: public String processexternaldata(byte[] extdata, String ifacetype) Página 127

136 En este método, ifacetype es el nombre del adapter (por ejemplo, Maximo). El método utiliza los datos XML y el adapter como parámetros y determina el remitente y la interface parseando el XML. Para invocar el EJB con el nombre de la interface y del remitente, se utiliza el siguiente método: public String processexternaldatawithparams(byte[] extdata, String ifacename, String sender) El cliente puede usar el nombre JNDI del Gateway EJB (syncmaximodataservice) para buscar la referencia EJB e invocar cualquier método. Además, necesita lo siguiente: Acceso a las clases remotas y locales de interface Acceso a los ficheros jar J2EE del servidor La URL del servidor que contiene el EJB El nombre de la clase del context factory El código del cliente debe instanciar el objeto InitialContext. El contexto deriva la URL y el context factory del entorno. Respuesta Si la invocación fue correcta, el EJB devuelve null. Si la invocación no fue correcta, el EJB lanza una excepción detallando el error Envío de transacciones vía HTTP/HTTPS Un servlet brinda la posibilidad de que los sistemas externos manden transacciones al integration Gateway vía HTTP Post. Para enviar las transacciones, se usa la siguiente URL: donde <dominio> es la máquina o el nombre del dominio y <adapter> es el nombre del adapter, por ejemplo Maximo. El tamaño máximo del mensaje que puede ser enviado a Maximo vía HTTP POST se controla por el parámetro IntegrationPostSize en el fichero web.xml de la aplicación meaweb. El valor por defecto es 5MB, aunque es posible cambiarlo a lo que se necesite. Por razones de Página 128

137 seguridad, un mensaje que excede del tamaño máximo es rechazado. Si se le envía un mensaje muy largo, es posible que se dé el error OutOfMemoryError cuando el parser XML intenta parsearlo. Si la transacción XML utiliza una codificación de caracteres distinta de UTF-8, el mensaje debe contener el atributo correspondiente, como se muestra a continuación: <?xml version= 1.0 encoding= ISO ?> Si el mensaje no contiene este atributo, Maximo asume que el mensaje XML utiliza la codificación UTF-8. Los datos XML deberían estar contenidos directamente en el cuerpo del mensaje HTTP Post. Para ello, cambiar el HTTP Content-Type header a text/xml. Respuesta Si la transacción se lleva a cabo correctamente, el servlet devuelve un código de estado 200 y el mensaje devuelto si hubiera, como parte del cuerpo de respuesta. El contenido de la respuesta es text/plain y la codificación es UTF-8. Si la transacción no se lleva a cabo correctamente, el servlet devolverá un código de estado 500 y el mensaje de error que se encontró. El contenido de la respuesta es text/plain y la codificación es UTF Envío de transacciones vía Gateway Web Service El Gateway Web service puede ser utilizado como una alternativa de enviar datos a Maximo. Los dos métodos descritos en Envío de transacciones vía EJB están disponibles para la invocación con un cliente vía SOAP-RPC. El código de cliente puede estar escrito en cualquier lenguaje y puede usar cualquier herramienta SOAP-RPC que trabaje con este lenguaje. Por ejemplo, en Java, cualquier implementación JAX-RPC puede ser usada para invocar este Web service. Para invocar este web service, el cliente debe usar los siguientes valores: Página 129

138 Parameter wsdl URL service name port name target namespace Value MEAGatewayService syncmaximodataservice Respuesta Si la invocación fue correcta, la respuesta es un mensaje SOAP con el cuerpo vacío. Si la invocación no fue correcta, la respuesta es un mensaje SOAP de fallo detallando el error Preguntas de Maximo A continuación se muestra una lista de preguntas frecuentes relativas a Maximo y a su integración con otros sistemas. Es el MEA la única interfaz de comunicación con Maximo? Sí, aunque también existen soluciones para comunicar Maximo con otros sistemas externos, como SAP, Microsoft Project o Primavera entre otros, lo único que estos adapters son paquetes opcionales que se adaptan a Maximo, requiriendo una licencia distinta. Tipo Maximo for Transportation En qué consiste el MEA? Maximo consta de varios EAR. Entre ellos, se encuentra maximo.ear, que contiene entre otros, meaweb.war, que es el módulo del MEA. Es opcional la instalación del MEA? Requiere algún tipo de licencia? La instalación del MEA es opcional. En el proceso de instalación de Maximo, se nos pregunta la posibilidad de instalar el MEA. Obviamente es necesario haber adquirido una licencia, suministrada con el MEA product Enabler para su posterior funcionamiento. Existe algún tipo de lógica en las aplicaciones de Maximo? No, simplemente existe lógica de datos. Qué aporta Maximo for Transportation? Maximo for Transportation (en adelante Transportation) se utiliza para gestionar activos como flotas o compontentes de transporte. Transportation incorpora varias mejoras a Maximo. Estas mejoras permiten incorporar información relativa a flotas y transportes, Página 130

139 como consumiciones de combustible, o contratos de garantía. Adicionalmente, se incorporan 14 nuevas aplicaciones para mejorar la gestión de activos, y 22 aplicaciones han sido clonadas, para añadir opciones o campos específicos para Transportation. Qué es un integration point exactamente y para qué sirve? Un integration point proporciona acceso a un integration object en una dirección dada (de entrada o de salida). Los integration points de salida, toman los datos de los MBOs para construir el integration object, mientras que los integration points de entrada crean, actualizan o hacen querys a los MBOs, dependiendo de la operación asociada con el point. Un integration object puede tener varios integration points asociados con él, en cualquier dirección. Los integration points tienen dos propiedades fundamentales: o Dirección: Para especificar si es de entrada o de salida o Operación: la operación indica el propósito del integration point. Puede ser Notify (para sincronizar datos), query (para consultar datos) o response (para dar respuestas a las querys). Algunas operaciones sólo se pueden dar en un sentido. Qué es un adapter? Todas las interfaces están definidas dentro de adapters, que son un conjunto de interfaces, programas, mapeos y controles. Por defecto, todas las interfaces proporcionadas con Maximo están definidas en el Maximo adapter. Qué se puede hacer con el Maximo Adapter? Las principales características del Maximo Adapter son: o o o o o Soporte de interfaces de query y synchronization. Exportación Bula de todas las interfaces, con la opción de seleccionar los datos vía querys de usuario. Capacidad de crear XML o ficheros planos para las interfaces de salida. Capacidad de llevar a cabo cargas bulk de XML y ficheros planos para las interfaces de entrada. Generación dinámica de esquemas XML para todos los integration objects e interfaces de Maximo adapters. Página 131

140 Qué es un internal/external adapter? Las interfaces definidas dentro de un internal type adapter derivan su contenido directamente desde los integration objects correspondientes, esto es, no existe diferencia entre el formato de datos del integration object y el formato de los datod del interface. Por lo contrario, las interfaces definidas dentro de un external type adapter, utilizan un formato de datos diferente al de Maximo. La transformación de los datos al formato de Maximo puede llevarse a cabo bien por medio de clases Java, o bien por hojas XSL. Cómo se hace el mapeo de las interface tables con el integration object? Las interface tables contienen una representación no jerárquica de las columnas de un integration object. La única operación soportada es Notify (data synchronization). Cuál es la diferencia entre Maximo web Services y Gateway web services? La diferencia reside en el comportamiento interno. Si utilizamos Maximo web Services, los mensajes que llegan a MEA, se colocan en las colas JMS de entrada, mientras que con el Gateway web services nos saltamos este paso. Qué se puede hacer con el User Exit processing? Cualquier tipo de procesado para modificar los datos de las interfaces o de los integration objects, depende de la etapa donde nos encontremos. Se puede llevar a cabo este procesado antes o después del procesado genérico de Maximo. También es posible generar eventos para llevar a cabo acciones dependiendo de condiciones. Cuáles son las reglas de funcionamiento de la integración de entrada por ficheros? Para integrar datos de entrada mediante ficheros, es necesario seleccionar la opción import data, lo que significa una importación manual. Tras haber seleccionado el fichero, Maximo lo borra. Si sólo hay lógica de datos en Maximo, En qué consisten las 36 aplicaciones de Maximo for Transportation? Transportation consta de 14 aplicaciones desarrolladas específicamente para tareas de mantenimiento de activos relacionados con el transporte. Además, se han copiado 22 aplicaciones estándar de Maximo, con la finalidad de añadir opciones y/o campos específicos para estas aplicaciones. Página 132

141 Cuál es el concepto de aplicación de Maximo? Las aplicaciones almacenan los datos en diferentes lugares, proporcionándonos una implementación multisite. Existen los siguientes niveles multisite: o Sistema o Base de Datos: Un sistema es una instancia de una base de datos de Maximo. Un sistema puede contener uno o más Sets, Organizations y Sites. o Set: Un Set se encuentra por debajo del nivel de Sistema, pero por encima del de Organización, para permitir compartir ítems y datos de compañías entre organizaciones. Cada Organization puede tener únicamente un Set. o Organization: Una organization representa una única entidad legal. Una compañía grande puede Constar de diferentes Organizations o diferentes compañías, o grupos de fábricas que, por ejemplo, se ubican en un mismo país o continente. Es posible contar con muchas organizaciones en una base de datos de Maximo. o Site: Un site identifica una ubicación de trabajo, como una planta o una fábrica. Las aplicaciones de Maximo se agrupan en módulos. Las aplicaciones de un módulo tienen propósitos similares, por ejemplo, las aplicaciones relativas a compras se agrupan juntas. Página 133

142 5. Integración Premises Maximo En este capítulo se detallarán los pasos a seguir para llevar a cabo la integración de Premises con Maximo, así como un ejemplo para detallar dicha integración de forma más intuitiva y eficaz. Dicho ejemplo trata de actualizar la lectura de un punto de medida de un activo en Maximo. Es decir, se dispone en Maximo de un activo (previamente creado), el cual tiene asociadas varios (o un) punto de medida (METER). A ese meter se le añadirán MeterReadings, que los proporcionará Premises. El sentido de esta demostración trata de simular un evento leído por un dispositivo físico conectado a un activo (en el ejemplo se puede suponer que el activo es un vehículo). Dicho dispositivo estará conectado con Premises (bien puede tener el Data Capture and Delivery en el propio Premises o en el dispositivo, puesto que esto no influirá en el funcionamiento), y enviará un evento simulando la lectura de un punto de medición. En el ejemplo se han definido tres puntos de medición, de los tres tipos distintos de medidas que existen predefinidos en Maximo. Estos puntos son los siguientes: FUEL-L: Este Meter está predefinido en Maximo. Se supone que refleja la cantidad de combustible en litros que se ha consumido por el vehículo. Este meter es de tipo acumulativo, así pues especificando valores, se interpretarán como valores delta y se irá incrementando el valor que contenga el meter. TEMP-C: Es el segundo Meter que se utilizará en el ejemplo. Este meter también se encuentra predefinido en Maximo, y simularía la temperatura de cualquier parte expresada en grados Centígrados que tendría el vehículo en un instante dado, que sería recogida por un sensor. Este meter tiene valor absoluto y real, por lo que cualquier valor que se introduzca, será interpretado como tal en Maximo (atendiendo, eso sí, a las restricciones de un valor real) OILCOLOR: El último Meter que se utiliza en el ejemplo de integración. Representa el color del aceite del vehículo en un instante dado. Este meter está predefinido en Maximo y es de tipo discreto. Esto quiere decir que puede tomar simplemente unos valores específicos. En este caso, sería posible que tomara los siguientes valores: o Brown o Turbid o Dark Página 134

143 Una vez definido el Asset en Maximo, incluyendo todos estos meters, se podrá comenzar a llevar a cabo el ejemplo de integración que se detalla a continuación. La integración consiste básicamente en el envío de un mensaje XML de Premises a Maximo. Como se ha comentado previamente, este ejemplo simula un evento enviado por un dispositivo conectado al bus CAN 15 de un vehículo. Se ha diseñado un servlet como el simulador de los eventos, donde se introducirá el ID del vehículo (en Maximo), así como un atributo, como es la lectura de combustible. Estos elementos son fácilmente referenciables en Maximo, y en particular, con el paquete Maximo for Transportation. Un ejemplo del mensaje que debería llegar a Maximo es el siguiente: 15 CAN es un protocolo de comunicaciones desarrollado por la firma alemana Robert Bosch GmbH, basado en una topología bus para la transmisión de mensajes en ambientes distribuidos, además ofrece una solución a la gestión de la comunicación entre múltiples CPUs (unidades centrales de proceso). El protocolo de comunicaciones CAN proporciona los siguientes beneficios: Es un protocolo de comunicaciones normalizado, con lo que se simplifica y economiza la tarea de comunicar subsistemas de diferentes fabricantes sobre una red común o bus. El procesador anfitrión (host) delega la carga de comunicaciones a un periférico inteligente, por lo tanto el procesador anfitrión dispone de mayor tiempo para ejecutar sus propias tareas. Al ser una red multiplexada, reduce considerablemente el cableado y elimina las conexiones punto a punto. Para simplificar aun más la electrónica del coche se puede utilizar una subred más simple, que se conecta a la red CAN, llamada LIN. Página 135

144 Donde se especifica: MXASSETInterface: Es la interface disponible para la integración con los activos (MXASSET). Header: Se envía con operación Notify, para indicar que se trata de una actualización. Dentro del contenido se especifican los siguientes campos: o o MXASSET: Nombre del MBO en Maximo ASSET: Con la operación de llevar a cabo cambios ASSETNUM: Este campo hace referencia al identificador del activo en Maximo ASSETMETER: Para indicar que se trata de una lectura del activo METERNAME: Maximo for Transportation define algunas medidas comunes en los activos de flotas, como es, por Página 136

145 ejemplo, FUEL-L, para indicar que es una lectura de combustible en Litros. MEASUREUNITID: Donde se indica la unidad de la medida. CHANGEBY: Este campo referencia a quién hizo la lectura en sí. NEWREADING: Donde se especifica la nueva lectura de combustible (se considera que se le añade combustible al mismo), en el ejemplo, se indica la acción Add, para indicar que es una nueva lectura, con valor 5 (5 litros añadidos). AVGCALCMETHOD: Para indicar el método de cálculo de media de combustible. Por defecto, se deja en ALL SITEID: Donde se indica la ubicación en la cual se ha llevado a cabo esta lectura. Una vez que conocemos el formato XML que le ha de llegar a Maximo, es necesario saber cómo se le enviará. Página 137

146 Ilustración 28. Flujo de los eventos Como se muestra en la Ilustración 28, los eventos recibidos por el dispositivo, serán recogidos por el Data Capture del Premises 6.1. Estos eventos, se los pasará al Data Transformation Center, y éste los pondrá en una cola MQ, llamada DC.IN.Q. Se puede ver este mismo flujo respecto a componentes software en la Ilustración 29 que se muestra a continuación. Página 138

147 Premises Server 6.1 Data Flow Microbroker DB EPCIS OSGi R4 Impl Persistence Filtering, Smoothing, Conversion Event Processor JVM J2SE WebSphere Messaging SI Bus Complex Event Processing DTS MQ Device Profile Device Profile Device Profile Event Processor WebSphere Process Server SAT / Profiles / Agents Microbroker Micro- Notifivc/Event SAT / Profiles Admin / Agents OSGI Notifivc/Event SAT / Profiles R4 Implementation Admin / Agents broker (Equinox) Microbroker JVM OSGI Notifivc/Event SAT / Profiles R4 + JCL Implementation 1.1 MinAdmin / Agents (Equinox) Microbroker Data JVM Capture OSGI Notifivc/Event R4 + JCL Implementation Node 1.1 MinAdmin (Equinox) Data JVM Capture OSGI R4 + JCL Implementation Node 1.1 Min (Equinox) Data JVM Capture JCL Node 1.1 Min Data Capture Node Premises Web Services 4/15/2008 IBM Confidential Ilustración 29. Flujo de datos de Premises Server 6.1 Posteriormente, dentro del Premises, los task agents suscritos a los topics del evento generado, lo tratarán y será enviado por el output channel correspondiente. En este caso, lo que se hará es enviarlo por un output channel HTTP, con el que el Integration Gateway de Maximo está conectado, y lo tratará. Página 139

148 El Integration Gateway lo transfiere a la cola de entrada y desde ahí, se llevará a cabo el flujo descrito en capítulos anteriores. Prerrequisitos A continuación se muestra la información requerida para la instalación del toolkit de WebSphere Premises Server. Hardware 2 GHz Pentium 4 (3 GHz preferidos) 2 GB RAM Software Windows XP Nota: WebSphere Premises Server Toolkit no está soportado en Linux. Rational Application Developer for WebSphere Software DB2 for Linux, UNIX, and Windows Enterprise edition or Oracle (10g driver) Página 140

149 Nota: Si se desea usar Oracle en un servidor remoto, es necesario contar con el cliente de Oracle. IBM HTTP Server 6.1 WebSphere MQ WebSphere Application Server fix pack instalado en el WebSphere Application Server runtime, el cual es instalado con el Rational Application Developer for WebSphere Software Nota: DB2 for Linux, UNIX, and Windows Workgroup Server edition también está soportado, pero no se incluye en el WebSphere Premises Server. 5.1 Parte Premises Añadir los proyectos al workspace Utilizar el wizard del WebSphere Premises Server Toolkit para añadir los proyectos al workspace actual del Racional Application Developer for WebSphere Software. 1. Seleccionar File > New > Other > IBM WebSphere Premises Server Toolkits > Premises Server Toolkit y hacemos click en Next 2. Hacemos click en Finish en el WebSphere Premises Server Toolkit. Página 141

150 5.1.1 Crear un server profile Esta tarea se lleva a cabo tanto en el Rational como en el WAS 1. En Rational Application Developer for WebSphere Software, navegar a Window > Preferences > Server > WebSphere y seleccionar Allow applications containing errors to be published on a server. 2. Hacer click en Create. 3. En la ventana Profile Management Tool, hacer click en Next. 4. En la ventana Environment Selection, seleccionar Application Server y hacer click en Next. 5. En la ventana Profile Creation Options, seleccionar Advanced profile creation y hacer click en Next. 6. En la siguiente ventana (Optional Application Deployment), desmarcar Deploy the default application y hacer click en Next. 7. En la ventana Profile Name and Location, introducir la siguiente información y hacer click en Next cuando se haya finalizado a. Para el nombre del perfil, introducir un nombre para el perfil del servidor, como RFIDTOOLKIT. b. Para el nombre del directorio, introducir un directorio para el perfil del servidor. Asegurarse de introducir un directorio fuera del directorio raíz (Por ejemplo C:\RFIDTOOLKIT). Utilizar el directorio por defecto podría causar errores de despliegue de la aplicación. c. Seleccionar Make this profile the default. 8. En la ventana Node y Host Names, aceptar los valores por defecto y hacer click en Next. 9. En la ventana Administrative Security, deseleccionar Enable administrative security y hacer click en Next. 10. Dentro de la ventana Port Values Assignment, hacer click en Default Port Values, y hacer click en Next. Esta selección hace que la consola administrativa de WebSphere Application Server esté disponible en el puerto 9060 y la consola administrativa de WebSphere Premises Server lo esté en el puerto En la ventana Windows Service Definition, desmarcar la opción Run the application process as a Windows service y hacer click en Next. Página 142

151 12. En la ventana Web Server Definition, aceptar los valores por defecto y hacer click en Next. 13. En la ventana de resumen titulada Profile Creation Summary, hacer click en Create. Esperar a que termine el proceso. 14. En la ventana titulada Profile Creation Complete, desmarcar Launch the First Steps console, y hacer click en Finish. 15. En la ventana Preferences, hacer click en OK. 16. Seleccionar File > New > Other > Server > Server y hacer click en Next. 17. En la ventana titulada Define a New Server, introducir los valores que se muestran a continuación, y pulsar Next cuando haya finalizado. a. Para el nombre del host, introducir localhost. b. Para el tipo de servidor, seleccionar IBM > WebSphere v6.1 Server c. Para el runtime del servidor, seleccionar WebSphere Application Server v En la ventana WebSphere Server Settings, llevar a cabo los siguientes valores y hacer click en Finish cuando haya finalizado. a. Para el nombre del perfil, seleccionar el perfil creado previamente (por ejemplo, RFIDTOOLKIT). El nuevo servidor para el nuevo perfil se encuentra en la vista servidores de Rational Application Developer for WebSphere Software Servers, y llamado WebSphere v6.1 localhost. 19. Hacer doble click en WebSphere localhost para abrir el editor del servidor. 20. En la sección de publicación, seleccionar Run server with resources on Server. 21. Seleccionar File > Save all. 22. Seleccionar File > Close all. Página 143

152 5.1.2 Configurar el server profile 1. En el Project Explorer del Rational Application Developer for WebSphere Software, expandir IBM > config. 2. Desde el menú del fichero config_premises.bat, seleccionar Open with > Text editor 3. Cambiar las siguientes variables a los valores correctos del sistema a. HTTP_INSTALL_DIR = Directorio de instalación del HTTP Server (Por ejemplo, C:\Program files\ibm\httpserver) b. MQ_INSTALL_DIR = Directorio de instalación de WebSphere MQ (Por ejemplo, C:\Program files\ibm\websphere MQ) c. RAD_INSTALL_DIR = Directorio de instalación del Rational Application Developer for WebSphere Software (Por ejemplo C:\Program Files\IBM\SDP70) d. RAD_WORKSPACE_DIR = Directorio dónde se encuentra el workspace del Rational Application Developer (por ejemplo, C:\workspace) e. WAS_PROFILE_NAME = Nombre del perfil que le hemos dado al servidor del WAS dentro del Rational Application Developer (por ejemplo, RFIDTOOLKIT) 4. Para DB2 cambiar estas variables: a. DB_INSTALL_DIR = Directorio de instalación de DB2 (por ejemplo, C:\Program Files\IBM\SQLLIB) b. DB_TYPE = db2 c. DB_HOSTNAME = nombre del host del servidor de bases de datos (Por ejemplo, localhost) d. DB_PORT_NUMBER = e. DB_NAME = IBMRFID f. DB_USERNAME = nombre del usuario de la base de datos (Por ejemplo, db2admin) g. DB_PASSWORD = contraseña del usuario de la base de datos 5. En el caso de que se esté utilizando una máquina que no tenga como lenguaje definido el US English, cambiar la siguiente variable al valor apropiado: a. DMS_BUNDLE_DIR = Raíz de documentos del servidor HTTP. 6. Guardar y cerrar el editor de textos. 7. Iniciar el servidor en la vista Servers. Página 144

153 8. Abrir una consola de Windows. 9. Cambiar el directorio a your_workspace\ibm\config 10. Ejecutar el script config_premises.bat. Esperar a que se complete el proceso. Ignorar errores como el siguiente: Log directory C:\workspace\IBM\RFID\logs exist The system cannot find the path specified. 11. Refrescar el proyecto IBM para ver los nuevos ficheros creados. 12. Reiniciar el servidor. 13. En la vista Servidores, desde el menú de WebSphere v6.1 localhost, seleccionar Add and remove projects. 14. Click Add all. 15. Click Finish y esperar a que se complete la acción. 16. Reiniciar el servidor. Página 145

154 5.1.3 Probar la configuración 1. Iniciar el servidor si aún no está iniciado. 2. Abrir una ventana del explorador web. 3. Comprobar que funciona la consola administrativa de WebSphere Premises Server: a. Dirigirse a b. Hacer click en Agent configuration dentro de la consola. Se muestra una lista de los agentes instalados en el sistema. 4. Comprobar la aplicación de Print, Verify and Ship: a. Ir a Un sistema configurado correctamente muestra una lista de todas las opciones en la lista Profile 5. Probar la consola administrativa de WebSphere Application Server: a. Dirigirse a Un sistema configurado correctamente muestra la consola administrativa de WebSphere Application Server. Página 146

155 5.1.4 Instalar el BIRT runtime El BIRT (Business Intelligence and Reporting Tools) es un plugin open source para Eclipse para crear y mostrar informes. Todos los informes del Websphere Premises Server son creados usando el BIRT. El WebSphere Premises Server Toolkit incluye el BIRT report designer, que es compatible con el BIRT utilizado por el WebSphere Premises Server. El BIRT no está instalado por defecto. Para instalar el runtime del BIRT, seguir los siguientes pasos: 1. Abrir una consola de Windows 2. Cambiar el directorio a your_workspace\ibm\rfid\premises\install\birt 3. Escribir set WAS_HOME=RAD_installation_dir\runtimes\base_v61, donde RAD_installation_dir es el directorio de instalación del Rational Application Developer for WebSphere Software. 4. Escribir set IBM_RFID_HOME=your_workspace\IBM\RFID. 5. Escribir birt_install.bat. 6. Reiniciar el servidor en el Rational Application Developer for WebSphere Software. Página 147

156 5.1.5 Crear un enterprise application project En este paso se creará un enterprise application project en Rational Application Developer for WebSphere Software. 1. En el Rational Application Developer for WebSphere Software, seleccionar File > New > Other > J2EE > Enterprise Application Project y hacer click en Next. 2. Completar las siguientes tareas en la ventana Enterprise Application Project a. Como nombre del proyecto, introducir FuelEvent_EAR b. Para el target runtime, seleccionar WebSphere Application Server v Hacer click en Finish. Ignorar los errores que aparezcan en el proyecto. Se corregirán más adelante. Página 148

157 5.1.6 Copiar los ficheros JAR requeridos El WebSphere Premises Server Toolkit incluye archivos Java (JAR) que se requieren cuando se crean soluciones de WebSphere Premises Server en el toolkit. Los JAR requeridos varían dependiendo del tipo de aplicación que deseemos crear. Todos los ficheros JAR están disponibles en el Toolkit en IBM > RFID > premises > api > lib. Para crear una aplicación que crea o procesa eventos, se ha de copiar los siguientes ficheros JAR: Amit3.0Common.jar com.ibm.rfid.tds.jar ibmrfid_common_utils.jar ibmse_common_util.jar ibmse_event_model_converter.jar ibmse_event_model_uuid.jar ibmse_event_model.jar ibmse_taskagent_runtime.jar org.apache.regexp.jar Para crear una aplicación que utilice el API de WebSphere Premises Server, los ficheros JAR que se muestran a continuación son requeridos: Rfid.jar com.ibm.rfid.tds.jar ibmrfid_alejavabeans.jar ibmrfid_common_utils.jar ibmrfid_premises_api_client.jar ibmrfid_premises_api_ejbclient.jar ibmrfid_premises_api_ws.jar ibmrfid_premises_util.jar org.apache.regexp.jar xsdbeans.jar Para crear una aplicación que utilice eventos y el API de WebSphere Premises Server, copiar todos los JAR. NOTA: En este ejemplo únicamente se procesan eventos. Página 149

158 Seguir estos pasos para copiar los ficheros JAR al enterprise application project que se creó: 1. En Rational Application Developer for WebSphere Software, seleccionar File > New > Other > General > Folder y hacer click en Next 2. Completar las tareas siguientes en la ventana Folder: a. Para el parent folder, seleccionar FuelEvent_EAR. b. Para el name folder, introducir lib. 3. Hacer click en Finish. 4. En la vista del Project Explorer, expandir IBM > RFID > premises > api > lib. 5. Seleccionar los siguientes ficheros y copiarlos: Amit3.0Common.jar com.ibm.rfid.tds.jar ibmrfid_common_utils.jar ibmse_common_util.jar ibmse_event_model_converter.jar ibmse_event_model_uuid.jar ibmse_event_model.jar ibmse_taskagent_runtime.jar org.apache.regexp.jar 6. Expandir el proyecto FuelEvent_EAR y pegar en la carpeta lib los JAR que habíamos copiado anteriormente. 7. Expandir la carpeta y comprobar que todos los ficheros se copiaron correctamente. Página 150

159 5.1.7 Crear un Java utility Project A continuación se creará un Java utility Project. Llevar a cabo los siguientes pasos para crear un Java Utility Project. 1. En Rational Application Developer for WebSphere Software, seleccionar File > New > Other > J2EE > Utility Project y hacer click en Next. 2. Completar las siguientes tareas en la ventana Utility Module. a. Para el nombre del proyecto, introducir FuelEvent_Java b. Para el nombre del proyecto, seleccionar FuelEvent_EAR. 3. Hacer click en Finish. Página 151

160 5.1.8 Modificar las dependencias J2EE del Java utility Project Antes de escribir cualquier código, hay que modificar las dependencias J2EE para que las JAR requeridas se encuentren en el CLASSPATH. Llevar a cabo los siguientes pasos para modificar las dependencias: 1. En la vista del Project Explorer, seleccionar FuelEvent_Java 2. Seleccionar File > Properties > J2EE Module Dependencias 3. Añadir los JAR siguientes al classpath: lib/amit3.0common.jar lib/com.ibm.rfid.tds.jar lib/ibmrfid_common_utils.jar lib/ibmse_common_util.jar lib/ibmse_event_model_converter.jar lib/ibmse_event_model_uuid.jar lib/ibmse_event_model.jar lib/ibmse_taskagent_runtime.jar lib/org.apache.regexp.jar 4. Hacer click en OK. Página 152

161 5.1.9 Crear la clase Java de utilidad Todas las clases de utilidad custom payload, deben heredar de IBMSensorEventPayload.class. Seguir los siguientes pasos para crear la clase de utilidad: 1. En Rational Application Developer for WebSphere Software, seleccionar File > New > Other > Java > Class y hacer click en Next. 2. Completar las siguientes tareas en la ventana Java Class. a. Para la source folder, introducir FuelEvent_Java/src b. Para el paquete, introducir com.fuel.event.payload. c. Para el nombre, introducir FuelEventPayload d. Para los modifiers, seleccionar Public. e. Para la superclase, introducir com.ibm.sensorevent.model.payload.ibmsensoreventpayload. 3. Hacer click en Finish. El editor para FuelEventReading.java se abre. 4. Cambiar el código fuente a lo siguiente: package com.fuel.event.reading; import com.ibm.sensorevent.model.ipayload; import com.ibm.sensorevent.model.generic.igenericgroup; import com.ibm.sensorevent.model.generic.sensoreventexception; import com.ibm.sensorevent.model.payload.ibmsensoreventpayload; public class FuelEventReading extends IBMSensorEventPayload { private static final long serialversionuid = 1L; //Constructor 1 protected FuelEventReading() throws SensorEventException{ } // Constructor 2 protected FuelEventReading(String eventtype) throws SensorEventException{ super(eventtype); } // Factory method 1 public static IGenericGroup getinstance() throws SensorEventException { return new FuelEventReading(); } // Factory method 2 public static IGenericGroup getinstance(string eventtype) throws SensorEventException { return new FuelEventReading(eventType); } // Factory method 3 public static IGenericGroup getinstance(ipayload sourcepayload) throws SensorEventException { FuelEventReading payload = (FuelEventReading) getinstance(); payload.copyfields(sourcepayload); copygroup(sourcepayload, payload); return payload; Página 153

162 } // Method 1 public String getreading() throws SensorEventException { return this.eventgroup.getstringattributevalue("reading"); } // Method 2 public void setreading(string reading) throws SensorEventException { this.eventgroup.addstringattribute("reading", reading); } public String getmetername() throws SensorEventException { return this.eventgroup.getstringattributevalue("metername"); } // Method 2 public void setmetername(string f) throws SensorEventException { this.eventgroup.addstringattribute("metername", f); } public String getavgcalcmethod() throws SensorEventException { return this.eventgroup.getstringattributevalue("avgcalcmethod"); } // Method 2 public void setavgcalcmethod(string f) throws SensorEventException { this.eventgroup.addstringattribute("avgcalcmethod", f); } public String getid() throws SensorEventException { return this.eventgroup.getstringattributevalue("id"); } } // Method 2 public void setid(string f) throws SensorEventException { this.eventgroup.addstringattribute("id", f); } 5. Seleccionar File > Save all. 6. Seleccionar File > Close all. Página 154

163 Crear un Task Agent MDB El WebSphere Premises Server maneja los eventos usando task agents. Todos los task agents son message-driven beans (MDBs) Crear un proyecto EJB Seguir los siguientes pasos para crear un proyecto EJB. 1. En el Rational Application Developer for WebSphere Software, seleccionar File > New > Other > EJB > EJB Project y hacer click en Next. 2. Completar las siguientes tareas en la ventana EJB Project a. Para el nombre del proyecto, introducir FuelEvent_EJB b. Para la membresía EAR, seleccionar Add Project to an EAR c. Para el nombre del proyecto EAR, introducir FuelEvent_EAR. 3. Hacer click en Finish Modificar las dependencias J2EE Antes de escribir código, modificar las dependencias J2EE para que los ficheros JAR requeridos se encuentren en el classpath. Seguir estos pasos para modificar las dependencias J2EE: 1. En la vista de Project Explorer, seleccionar FuelEvent_EJB 2. Seleccionar File > Properties > J2EE Module Dependencias 3. Añadir los JAR siguientes al classpath: TemperatureEvent_EJBClient.jar TemperatureEvent_Java.jar lib/amit3.0common.jar lib/com.ibm.rfid.tds.jar lib/ibmrfid_common_utils.jar lib/ibmse_common_util.jar lib/ibmse_event_model_converter.jar lib/ibmse_event_model_uuid.jar lib/ibmse_event_model.jar lib/ibmse_taskagent_runtime.jar lib/org.apache.regexp.jar 4. Hacer click en OK. Página 155

164 Crear el task agent MDB Todos los task agents deben heredar de la clase IBMSEAbstractTaskAgent. Para crear el task agent MDB, seguir los siguientes pasos: 1. En Rational Application Developer for WebSphere Software, seleccionar FuelEvent_EJB. 2. Seleccionar File > New > Other > EJB > Enterprise Bean y hacer click en Next. 3. Completar las siguientes tareas en la ventana Enterprise Bean a. Seleccionar Message-drive bean. b. Para el nombre del proyecto, seleccionar FuelReading_EJB. c. Para el nombre del bean, introducir FuelEventTaskAgent. d. Para la carpeta contenedora, introducir ejbmodule. e. Para el paquete por defecto, introducir com.fuel.event.mdb. 4. Hacer click en Next. 5. En la ventana Message-Driven Bean Type, Seleccionar JMS Type y hacer click en Next. 6. En la ventana Create a JMS Message-Driven Bean, aceptar todos los valores por defecto y hacer click en Next. 7. En la ventana EJB Java Class Details, introducir com.ibm.sensorevent.engine.baseagent.ibmseabstracttaskagent para la superclase del bean. 8. Hacer click en Next 9. Si aparece la ventana de Confirm Enablement, seleccionar Always enable activities and don t ask me again y hacer click en OK. 10. Cerrar el editor de diagramas (default.dnx) cuando se abra. No se usará. 11. En la vista de Project Explorer, expandir FuelEvent_EJB > ejbmodule > com.fuel.event.mdb 12. Hacer doble click en FuelEventTaskAgentBean.java para abrir el editor. Es posible que salten errores en el código que serán corregidos en el siguiente paso. 13. Cambiar el código fuente al siguiente package com.fuel.event.mdb; import com.ibm.sensorevent.model.ipayloadmetadata; import com.ibm.sensorevent.model.isensorevent; import com.fuel.event.reading.fueleventreading; /** * Bean implementation class for Enterprise Bean: TemperatureEventTaskAgent Página 156

165 */ public class FuelEventTaskAgentBean extends com.ibm.sensorevent.engine.baseagent.ibmseabstracttaskagent implements javax.ejb.messagedrivenbean, javax.jms.messagelistener { private static final long serialversionuid = 1L; private javax.ejb.messagedrivencontext fmessagedrivenctx; // Method 1 protected void onibmsensorevent(isensorevent event){ try{ // display the event data FuelEventReading reading = (FuelEventReading) event.getpayload(); String id = reading.getid(); System.out.println("task agent: ID = " + id); System.out.println("task agent: meter = " + reading.getmetername()); System.out.println("task agent: reading = " + reading.getreading()); System.out.println("task agent: unit = " + reading.getavgcalcmethod()); // add sample data to event metadata IPayloadMetaData metadata = event.getpayloadmetadata(); metadata.addbooleanattribute("processed", true); } //forward event to output channels this.publishoutbound(event); }catch(exception e){ e.printstacktrace(); } // Method 2 public void onmessage(javax.jms.message msg) { super.onmessage(msg); } public javax.ejb.messagedrivencontext getmessagedrivencontext() { return fmessagedrivenctx; } public void setmessagedrivencontext(javax.ejb.messagedrivencontext ctx) { fmessagedrivenctx = ctx; } public void ejbcreate() { } public void ejbremove() { } } 14. Seleccionar File > Save all 15. Seleccionar File > Close all Modificar el EJB deployment descriptor Después de crear el MDB, modificar el EJB deployment descriptor. 1. En la vista de Project Explorer, expandir FuelEvent_EJB 2. Hacer doble click en Deployment Descriptor: FuelEvent_EJB. El deployment descriptor EJB se abrirá. Página 157

166 3. En la sección Enterprise JavaBeans de la página de resumen del deployment descriptor del EJB, hacer click en FuelEventTaskAgent. La página del Bean se muestra. 4. Buscar en el panel de la parte superior derecha la sección Activation Configuration y hacer click en Add 5. Completar los pasos siguientes en la ventana Add Activation Configurations. a. Para el nombre, seleccionar destinationtype. b. Para el valor, seleccionar javax.jms.topic. 6. Hacer click en Finish. 7. Hacer buscar en el panel inferior de la derecha de la ventana para encontrar la sección de WebSphere Bindings y completar las tareas siguientes: a. Seleccionar JCA Adapter. b. Para el nombre JNDI ActivationSpec, introducir eis/fueleventas 8. Seleccionar File > Save All. 9. Seleccionar File > Close All Configurar el WebSphere Application Server para gestionar un evento con el custom payload Para hacer que el WebSphere Application Server haga llegar un evento a un task agent MDB, crear un topic en el WebSphere Application Server y una activation Specification. Llevar a cabo los siguientes pasos para configurar el WebSphere Application Server. 1. Iniciar el servidor configurado en la vista Servers del Rational Application Developer for WebSphere Software. 2. Abrir un explorador web y dirigirse a para acceder a la consola administrativa del WebSphere Application Server. 3. Hacer click en Log in. No se requiere usuario. 4. Seleccionar Resources > JMS > Topics. 5. Expandir la sección Scope y seleccionar el Node scope. (No Node and Server) 6. Hacer click en New. 7. Seleccionar Default messaging provider 8. Click Ok. 9. Completar las siguientes tareas en la sección de configuración: a. For the Name, enter fuel.event.topic. b. For the JNDI name, enter jms/fuel.event.topic Página 158

167 c. For the Topic name, enter ibmse//fuel/event. The two forward slashes (//) between ibmse and fuel are required. The syntax for this value is ibmse//event_type. d. For the Bus name, select ibmsensorevent. e. For the Topic space, select ibmse. 10. Hacer click en OK. 11. Hacer click en Save para completar la creación del topic. 12. Seleccionar Resources > JMS > Activation specifications. 13. Expandir la sección Scope y seleccionar el Node scope (no el Node y Server) 14. Hacer click en New. 15. Seleccionar Default Messaging provider 16. Hacer click en OK. 17. Completar las tareas siguientes en la sección de configuración: a. For the Name, enter TemperatureEventAS. b. For the JNDI name, enter eis/temperatureeventas. c. For the Destination type, select Topic. d. For the Destination JNDI name, enter jms/temperature.event.topic. e. For the Bus name, select ibmsorevent. 18. Hacer click en OK. 19. Hacer click en Save para completar la creación de la activation specification Modificar el message selector para el activation specification PersistenceAS Por defecto, la persistencia de WebSphere Premises Server sólo captura los eventos de lectura de tags RFID así como eventos lecturas de tags. El conjunto de eventos llevados por la persistence está gobernado por el message selector para el activation specification Persistencias. Cuando se toma persistencia de un evento por el WebSphere Premises Server, es posible crear informes BIRT personalizados para mostrar información de eventos. Llevar a cabo los siguientes pasos para modificar el message selector para el activation specification PersistenceAS para incluir el evento con el custom payload. 1. En la consola administrativa del WebSphere Application Server, seleccionar Recursos > JMS > Activation specifications > PersistenceAS. 2. Para el Message selector, introducir ibmse LIKE '%/fuel/event' OR ibmse='rfidinventory/tagreport' OR Página 159

168 ibmse='rfidinventory/tagaggregationreport' OR ibmse LIKE '%/report/tagreport' OR ibmse LIKE '%/report/tagaggregationreport'. La sintaxis para añadir el evento con el custompaylad es ibmse LIKE 'event_type' con cada condicional separado por OR. 3. Hacemos click en OK. 4. Hacer click en Save para completar la modificación del PersistenceAS activation specification. 5. Salir de la consola administrativa del WebSphere Application Server. Página 160

169 Configurar el WebSphere Premises Server En este ejemplo, el MDB task agent, publica un evento a todos los canales de salida (output channels) registrados, en los cuales el nombre del evento corresponde a la plantilla configurada en WebSphere Premises Server. En este ejemplo, el perfil del evento es EDDR y el tipo de evento es fuel/event. Cuando es enviado a WebSphere Premises Server, este evento se publica al topic ibmse/eddr/fuel/event. Por tanto, el template del WebSphere Premises Server debe ser */*/fuel/event. Seguir los siguientes pasos para configurar el WebSphere Premises Server: 1. Asegurarse que el perfil configurado de WebSphere Application Server está ejecutándose en la vista Servidores del Rational Application Developer for WebSphere Software. 2. Abrir un explorador web y dirigirse a para acceder a la consola administrative de WebSphere Premises Server. 3. En la consola administrativa del WebSphere Premises Server, seleccionar Event Processing Configuration > Event Templates. 4. Hacer click en New. 5. Completar las siguientes tareas en la página Create Event Template: o Para el nombre del template, introducir */*/fuel/event. o Para la descripción, introducir Fuel Event Template. o En la lista de canales disponibles, seleccionar enterprise.out.channel : JMS. o Hacer click en ->. o Hacer click en Create Event Template. Con estos pasos ya tendríamos el Premises Server listo para recoger eventos. No obstante, puesto que el evento ha de ser generado por algún dispositivo, en este ejemplo lo que se hará será hacer un simulador de eventos, que no será más que un servlet que enviará al Premises un evento simulando el reporte de un dispositivo a Premises acerca del funcionamiento, por ejemplo, de un vehículo. Página 161

170 Creación del proyecto Web Seguir los pasos siguientes para crear un proyecto web: 1. Reiniciar el servidor en la vista de servidores dentro del Rational Application Developer for WebSphere Software para activar los cambios hechos en la consola administrativa del WebSphere Application Server y del WebSphere Premises Server. 2. En el Rational, seleccionar File > New > Other > Dynamic Web Project y hacer click en Next. 3. Completar las siguientes tareas en la ventana Dynamic Web Project: a. Para el nombre del proyecto, introducir FuelEvent_Web b. Para la membresía del EAR, seleccionar Add Project to an EAR. c. Para el nombre del proyecto, introducir FuelEvent_EAR. 4. Hacer click en Finish. 5. Si se nos pregunta acerca de abrir la perspectiva asociada, hacer click en No. 6. Cerrar el editor de diagramas (WebDiagram.gph) cuando se abra. No se utilizará. Página 162

171 Modificar las dependencias J2EE del proyecto Web Antes de escribir código, es necesario modificar las dependencias J2EE para que los ficheros JAR requeridos se encuentren en el classpath. Llevar a cabo los siguientes pasos para modificar las dependencias J2EE del proyecto Web: 1. En la vista de explorador de proyectos (Project Explorer), seleccionar FuelEvent_Web. 2. Seleccionar File > Properties > J2EE Module Dependencias. 3. Añadir los siguientes ficheros JAR al classpath: TemperatureEvent_EJBClient.jar TemperatureEvent_Java.jar lib/amit3.0common.jar lib/com.ibm.rfid.tds.jar lib/ibmrfid_common_utils.jar lib/ibmse_common_util.jar lib/ibmse_event_model_converter.jar lib/ibmse_event_model_uuid.jar lib/ibmse_event_model.jar lib/ibmse_taskagent_runtime.jar lib/org.apache.regexp.jar 4. Hacer click en OK. Página 163

172 Crear el servlet Seguir los pasos siguientes para crear el servlet: 1. En el Rational Application Developer for WebSphere Software, seleccionar FuelEvent_Web. 2. Seleccionar File > New > Other > Web > Servlet y hacer click en Next. 3. Completar las siguientes tareas en la ventana Create Servlet. a. Para el nombre del proyecto, seleccionar FuelEvent_Web. b. Para la carpeta, introducir \FuelEvent_Web\src. c. Para el paquete Java, introducir com.temperature.event.web. d. Para el nombre de la clase, introducir FuelEventServlet 4. Hacer click en Finish. El editor se abrirá. 5. Copiar el código fuente al siguiente: /********************************************************************************** * Licensed Materials - Property of IBM * 5724-L17 WebSphere Premises Server * (c) Copyright IBM Corp All rights reserved. * * US Government Users Restricted Rights - Use, duplication or disclosure * restricted by GSA ADP Schedule Contract with IBM Corp. * * DISCLAIMER OF WARRANTIES. The following code is sample code created by * IBM Corporation. This sample code is part of the WebSphere Premises Server * and is warranted to perform its intended function only if used un-modified. * If you modify this code then it is considered provided "AS IS", without * warranty of any kind. Notwithstanding the foregoing, IBM shall not be liable * for any damages arising out of your use of the sample code, even if they have * been advised of the possibility of such damages. ***********************************************************************************/ package com.fuel.event.web; import java.io.dataoutputstream; import java.io.ioexception; import java.io.inputstream; import java.io.printwriter; import java.net.httpurlconnection; import java.net.url; import java.net.urlencoder; import java.util.random; import javax.servlet.servletexception; import javax.servlet.http.httpservletrequest; import javax.servlet.http.httpservletresponse; import com.ibm.sensorevent.model.ibmsensorevent; import com.ibm.sensorevent.model.isensorevent; import com.ibm.sensorevent.model.converter.xmlconverter; import com.fuel.event.reading.fueleventreading; public class FuelEventServlet extends javax.servlet.http.httpservlet implements javax.servlet.servlet { private static final long serialversionuid = 1L; public FuelEventServlet() { super(); } Página 164

173 protected void doget(httpservletrequest request, HttpServletResponse response) throws ServletException, IOException { this.dopost(request, response); } protected void dopost(httpservletrequest request, HttpServletResponse response) throws ServletException, IOException { try { String metername = null; String avgcalcmethod = null; String meterreading = null; String id = new String("C1234"); // create the event String profile = "EDDR"; String eventtype = "fuel/event"; FuelEventReading reading = (FuelEventReading) FuelEventReading.getInstance(profile + "/" + eventtype); if(request.getparameter("txtid")!= null){ id = (String) request.getparameter("txtid"); } if(request.getparameter("type_meter").equalsignorecase("fuel")){ if(request.getparameter("txtfuel")!= null){ try{ Integer.parseInt(request.getParameter("txtFuel")); meterreading = request.getparameter("txtfuel"); }catch(numberformatexception nfex){ meterreading = "12"; } } metername = "FUEL-L"; avgcalcmethod = "LTRS"; } if(request.getparameter("type_meter").equalsignorecase("oil")){ if(request.getparameter("cmboil")!= null){ meterreading = request.getparameter("cmboil").tostring(); } metername = "OILCOLOR"; } if(request.getparameter("type_meter").equalsignorecase("temperature")){ if(request.getparameter("txttemperature")!= null){ try{ Integer.parseInt(request.getParameter("txtTemperature")); meterreading = request.getparameter("txttemperature"); }catch(numberformatexception nfex){ meterreading = "20"; } } metername = "TEMP-C"; avgcalcmethod = "DEG C"; } reading.setmetername(metername); reading.setavgcalcmethod(avgcalcmethod); reading.setreading(meterreading); reading.setid(id); ISensorEvent event = IBMSensorEvent.getInstance(profile + "/" + eventtype, reading); event.getheader().setsourceid("e2"); // convert to XML Página 165

174 XMLConverter converter = (XMLConverter) XMLConverter.getInstance(); String xml = converter.toxmlstring(event); // send the XML to the Premises Server gateway this.sendtogateway(xml); // display a result in the browser PrintWriter pw = response.getwriter(); response.setcontenttype("text/html"); pw.println("<p>sample Event Sent</P>"); pw.println("<p>id = '"+ id +"'</P>"); pw.println("<p>meter = " + metername + "</P>"); pw.println("<p>meterreading = " + meterreading + "</P>"); pw.println("<p>meterunit = " + avgcalcmethod + "</P>"); } } catch (Exception e) { e.printstacktrace(); } private void sendtogateway(string xml) throws Exception { String urlstring = " URL url = new URL(urlString); HttpURLConnection connection = (HttpURLConnection) url.openconnection(); connection.setrequestmethod("post"); connection.setrequestproperty("content-type", "application/x-www-formurlencoded"); connection.setusecaches(false); connection.setdoinput(true); connection.setdooutput(true); connection.connect(); StringBuffer data = new StringBuffer(); data.append("eventxml=" + URLEncoder.encode(xml, "UTF-8")); DataOutputStream dos = new DataOutputStream(connection.getOutputStream()); dos.writebytes(data.tostring()); dos.flush(); dos.close(); } } // getting the response is required to force the request; // otherwise, it might not even be sent at all InputStream is = connection.getinputstream(); is.close(); 6. Seleccionar File > Save All. 7. Seleccionar File > Close All. 8. Creamos ahora el JSP para ya terminar el simulador de eventos. Dicho fichero ha de guardarse en WebContent/jsp. Para ello, creamos una nueva carpeta en WebContent y la llamamos jsp. 9. Hacemos click en File > New > Other > JSP File y lo llamamos index.jsp 10. Borramos el código que nos genera y lo reemplazamos por el siguiente: <%@ page language="java" contenttype="text/html; charset=iso " pageencoding="iso "%> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" " <html> <head> <meta http-equiv="content-type" content="text/html; charset=iso "> <title>fuel Reading</title> </head> <body> Página 166

175 <p>fuel Reading</p> <form method="post" action="/fuelreading_web/fueleventservlet"> <table> <tbody> <tr> <td>id</td> <td><input type="text" name="txtid" size="20" value="c1234"></td> </tr> <tr> <td><input type="radio" name="type_meter" value="fuel">fuel Reading</td> <td><input type="text" name="txtfuel" size="20" value="12"></td> </tr> <tr> <td><input type="radio" name="type_meter" value="oil">oil Color</td> <td><select name="cmboil"> <option value="turbid" selected>turbid</option> <option value="brown">brown</option> <option value="clear">clear</option> </select></td> </tr> <tr> <td><input type="radio" name="type_meter" value="temperature">temperature</td> <td><input type="text" name="txttemperature" size="20" value="20"></td> </tr> </tbody> </table> <input type="submit" name="btnsend" value="send" ></form> </body> </html> En este ejemplo ya se tiene listo el simulador de eventos. Para comunicar en este punto Premises con Maximo, crearemos un Output Channel de tipo HTTP, para que Premises sea el encargado a través de dicho output channel de enviar el evento transformado mediante una hoja XSLT a Maximo. Página 167

176 Creación y definición del output channel A continuación se muestran los pasos necesarios para crear el HTTP Output Channel para la redirección del mensaje de Premises a Maximo. 1. Asegurarse que el servidor configurado está ejecutándose. 2. Abrir un explorador web y dirigirse a la consola administrativa de WebSphere Premises Server, la cual se encuentra en la dirección 3. En la consola administrativa, hacer click en Output Channels dentro de la sección Event Processing Configuration 4. Seleccionamos HTTP Output Channel y hacemos click en New 5. Introducimos los siguientes valores: a. Para el Channel ID: Introducimos el identificador del canal de salida, por ejemplo, http to servlet b. Para la descripción no introducimos nada. c. Para la clase de transformación, introducimos Este archivo se ubicará más adelante. d. Para la URL, introducimos la dirección del servlet del Gateway de Maximo. En el ejemplo, El servlet del Gateway se encuentra por defecto siempre en la dirección sistema> 6. Hacemos click en Create. 7. Creamos la clase xsl de transformación con el bloc de notas, e introducimos el siguiente código: <?xml version="1.0" encoding="iso "?> <xsl:stylesheet version="1.0" xmlns:xsl=" <xsl:output method="xml" indent="yes"/> <xsl:template match="/"> <xsl:variable name="unit"><xsl:value-of select="commonbaseevent/extendeddataelements[@name='ibmse_payload']/ch ildren/children[@name='avgcalcmethod']/values"/></xsl:variable> <MXASSETInterface xmlns=" xmlns:xsi=" language="en"> <Header operation="notify"> <SenderID>PREMISES</SenderID> <CreationDateTime><xsl:value-of select="commonbaseevent/extendeddataelements[@name='ibmse_header']/chi ldren[@name='datetime']/values"/></creationdatetime> </Header> Página 168

177 <Content> <MXASSET> <ASSET action="change"> <ASSETNUM><xsl:value-of <ASSETMETER action="change"> <METERNAME><xsl:value-of <xsl:if test="$unit!= 'null'"> <xsl:variable name="mynewstring"> <xsl:call-template name="replacecharsinstring"> <xsl:with-param name="stringin" select="string($unit)"/> <xsl:with-param name="charsin" select="'%20'"/> <xsl:with-param name="charsout" select="' '"/> </xsl:call-template> </xsl:variable> <MEASUREUNITID><xsl:value-of select="string($mynewstring)"/></measureunitid> </xsl:if> <CHANGEBY>MAXADMIN</CHANGEBY> <NEWREADING action="add"><xsl:value-of <AVGCALCMETHOD>ALL</AVGCALCMETHOD> </ASSETMETER> <SITEID>BEDFORD</SITEID> </ASSET> </MXASSET> </Content> </MXASSETInterface> </xsl:template> <!-- here is the template that does the replacement --> <xsl:template name="replacecharsinstring"> <xsl:param name="stringin"/> <xsl:param name="charsin"/> <xsl:param name="charsout"/> <xsl:choose> <xsl:when test="contains($stringin,$charsin)"> <xsl:value-of select="concat(substringbefore($stringin,$charsin),$charsout)"/> <xsl:call-template name="replacecharsinstring"> <xsl:with-param name="stringin" select="substring-after($stringin,$charsin)"/> <xsl:with-param name="charsin" select="$charsin"/> <xsl:with-param name="charsout" select="$charsout"/> </xsl:call-template> </xsl:when> <xsl:otherwise> <xsl:value-of select="$stringin"/> </xsl:otherwise> Página 169

178 </xsl:choose> </xsl:template> </xsl:stylesheet> 8. Movemos dicho fichero al directorio raíz del servidor HTTP. Dicho directorio se encuentra por defecto (y en caso de que el idioma por defecto sea el Inglés norteamericano) en c:\program Files\IBM\HTTPServer\htdocs\en_US 9. Comprobamos que el fichero se ha ubicado correctamente abriendo un explorador web y navegando a la dirección Reiniciar el WebSphere Application Server para que se apliquen los cambios realizados. Errores en el Output Channel El HTTP Output Channel se quedará a la espera de recibir el código de retorno del destino a donde haga el post. Si el código de respuesta es inferior a 200 o superior a 299, el Output Channel lanzará una Exception. Dicha Exception podrá verse en el log del perfil de Premises. El mensaje se guarda en la cola ENTERPRISE.OUT.Q a la espera de ser procesado. Página 170

179 5.2 Parte Maximo A continuación se mostrarán los pasos necesarios a dar en Maximo para llevar a cabo la integración Prerrequisitos Contar con una instalación correcta de Maximo incluyendo el Maximo Enterprise Adapter. Adicionalmente, en el entorno de desarrollo del ejemplo, se encuentra instalado también el Maximo for Transportation, aunque para llevar a cabo la integración no es necesario Integración A continuación se muestran los pasos necesarios para configurar Maximo para llevar a cabo la integración con Premises, aunque estos pasos también pueden llevarse a cabo para integrar Maximo con otro sistema externo. 1. Iniciar sesión en Maximo como maxadmin. Página 171

180 2. Ir a la aplicación de sistemas externos. Para ello, Go to Integration External Systems. Página 172

181 3. Refrescamos los sistemas externos disponibles pulsando Enter en el cuadro de texto System. Página 173

182 a. Pinchamos sobre EXTSYS1. Página 174

183 4. En el menú de acciones, hacemos click en Duplicate External System. NO MODIFICAR ESTE SISTEMA EXTERNO. 5. Se duplicará el sistema externo. Introducimos los siguientes parámetros: a. System: PREMISES. b. Enabled: true. c. Colas: Se dejan las de por defecto. d. Adapter: Por defecto (MAXIMO). e. End Point: MXXMLFILE. f. Hacemos click en el botón de guardar. Página 175

184 6. Desde el menú de acciones en el sistema externo recién creado (PREMISES), hacemos click en Integration Administration Setup a. En el Maximo user name for inbound processing, introducimos el valor maxadmin. b. El Global Directory Location, es el directorio local que será usado para todos los ficheros de esquema, ficheros XML y de error. Estos ficheros están predefinidos en directorios dentro del directorio global. Por defecto, esta propiedad no tiene valor, y los ficheros se ubican en el mismo directorio donde se encuentran los logs de Maximo. Introduciremos un valor, por ejemplo, C:\MEA. c. La opción Update SENDERSYSID on Data Export especifica si Maximo debe escribir el identificador del sistema de Maximo (el valor de MAXVARS.MXSYSID) en el campo SENDERSYSID cuando se genera una transacción por la acción Data Export. El valor por defecto es no. Este ajuste únicamente afecta a transacciones de salida. Mantenemos el valor por defecto. d. Hacemos click en OK. Página 176

185 e. Guardamos el sistema externo. 7. Deshabilitar las interfaces que no usamos a. Hacemos click en la pestaña Outbound Interfaces Página 177

186 b. Desmarcamos en todas las interfaces, la casilla Enabled? En todas las páginas. Página 178

187 c. Hacemos click en Guardar d. Nos vamos a la pestaña Inbound Interfaces e. Desmarcamos en todas las interfaces la casilla Enabled? Excepto en el interfaz MXASSETInterface f. Hacemos click en Guardar. 8. Reiniciamos el Servidor de Maximo 9. Hacemos una prueba de integración con el intclient con HTTPPost enviándole el siguiente fichero XML. Deberá crear un Asset con código C1234. Para comprobar que funciona, nos dirigimos al módulo Assets, y a la aplicación Assets. Ahí, en la caja de texto introducimos el código C1234. Si aparece dicho asset, está correctamente configurado. En caso contrario, asegurarse que se han realizado correctamente todos los pasos. Página 179

188 <?xml version="1.0" encoding="utf-8"?> <MXASSETInterface xmlns=" xmlns:xsi=" language="en"> <Header operation="notify"> <SenderID>PREMISES</SenderID> <CreationDateTime> T11:54:35+01:00</CreationDateTime> </Header> <Content> <MXASSET> <ASSET action="add"> <ASSETNUM>C1234</ASSETNUM> <SITEID>BEDFORD</SITEID> </ASSET> </MXASSET> </Content> </MXASSETInterface> Página 180

189 6. Pruebas 6.1 Plan de Pruebas Para la correcta gestión de las pruebas, se define un plan de pruebas para comprobar el correcto funcionamiento del proyecto de integración. El objetivo principal de la fase es someter al sistema desarrollado y sus componentes, a una serie de verificaciones encaminadas a garantizar un nivel de fiabilidad aceptable. Si los resultados de las pruebas son aceptables, se procederá a la aceptación de las mismas y a la implantación del sistema, pero en caso contrario habrá que subsanar las anomalías encontradas, lo que significaría volver al diseño realizado Entorno de pruebas o certificación Se establece el entorno de pruebas con la siguiente arquitectura: Premises 6 Owasys owa22a IBM eserver xseries RY IBM Maximo Asset Management IBM Maximo Spatial Opcional Intermec IF5 Ejemplos de Dispositivos ArcGIS Server Ilustración 30. Diagrama de la arquitectura Página 181

190 Como se puede observar en la Ilustración 30, tanto el Premises 6.1 como el IBM Maximo Asset Management, IBM Maximo Spatial y el ArcGIS Server se ejecutarán en sendas máquinas virtuales, que a su vez se ejecutarán en un único servidor físico, el IBM eserver xseries RY. Las máquinas virtuales estarán basadas en imágenes VMWare con versión Tipos de Pruebas A continuación se definen los tipos de pruebas que han de llevarse a cabo para la realización del sistema. Pruebas de Integración: Verifican la correcta operación del sistema integrado, y el rendimiento de los recursos utilizados. Estas pruebas son las más críticas, puesto que el propósito del proyecto es conseguir la integración entre los dos sistemas descritos durante todo el documento. 6.2 Resumen de pruebas A continuación se mostrará un resumen de las pruebas. Dichas pruebas consisten en comprobar el correcto funcionamiento del MEA bajo Premises al actualizar meters en un Asset. Página 182

191 VM1 VM2 VM3 Origen O1 O2 O1 Versión Maximo Transportation 6.3 NO NO Pruebas previas SI NO NO Test 1 (intro. Assets) Comportamiento anormal Comportamiento considerado correcto Comportamiento considerado correcto Resultados Deja introducir datos en campos R/O, no muestra lastreading en Gauge y Characteristic Intenta instalar transportation sin éxito Funcionamiento aparentemente normal Test 2 (MEA) Añade readings & assets id NO Resultados Crea readings, pero no aparece el lastreading en Gauge y Characteristic No error, no crea readings, pero crea Assets No error, no crea readings, pero crea Assets Creación de un Asset Goto Assets (Tr) New Asset Introducimos los datos marcados con un asterisco. o o Asset C1111 Type FLEET o Purchase Price: 10,000 o Replacement Cost: 1,000 o Budgeted Cost: 10,000 Meters: o o New Row RUNHOURS (CONTINUOUS) READING TYPE: DELTA ACCEPT ROLLDOWN FROM: ASSET AVERAGE CALCULATION METHOD: ALL o o TEMP-C (GAUGE) VIBRATION (CHARACTERISTIC) Página 183

192 Resultado Tal y como se crea, no permite añadir nada en Last Reading en la Meter RUNHOURS, sin embargo, en TEMP-C y VIBRATION si. Cambiamos el estado a OPERATING o Change Status New Status: OPERATING Resultado El estado se cambia correctamente Se añaden Meter Readings a los distintos tipos de activos A través del menú de Acciones, Meter Readings Enter Meter Readings RUNHOURS TEMP-C VIBRATION Se añade un 2 en todos los meters. Resultado Sólo aparece el Last Reading en RUNHOURS, de tipo continuo. Se añaden valores en Last Reading de TEMP-C o LastReading 1 o Last Reading Date: 5/14/08 10:09 AM o Last Reading Inspector: DALEY Resultado No aparece en el informe de Meters de Maximo. En la ayuda se indica lo siguiente: Gauge meters are recorded via condition monitoring points. Characteristic meters are recorded via condition monitoring points. Página 184

193 Pruebas con el Condition Monitoring Goto Assets Condition Monitoring Se hace un condition monitoring para el Asset C1111, y se fijan los umbrales de aviso y de acción. Se fija que para el umbral de acción tanto alto como bajo, se generen WorkOrders Resultado Con respecto a los meter readings, sigue sin aparecer en el campo. Sin embargo, los condition monitoring funcionan correctamente (emiten órdenes de trabajo al introducir nuevas meters). Se vuelven a ejecutar las pruebas en un Maximo limpio LastReading se muestra para todos los tipos de Meters. Se ejecutan las pruebas en el Maximo descargado en /local/virtualmachines LastReading se muestra para todos los tipos de Meters. Se ejecutan pruebas de integración en un Maximo limpio Se crea un sistema externo que se llama PREMISES. Se testea con el intclient y se utilizan distintos ficheros XML para comprobar el funcionamiento. El primero de ellos para crear un Asset, y el segundo para introducir meters del asset. Al introducir las meters del asset, no se muestra ningún error ni en el servlet, ni en las colas. No se actualiza el meter, pero sí el asset, lo que quiere decir que, El transportation añade la posibilidad de añadir meters La instalación inicial no está funcionando correctamente Se ejecutan pruebas de integración en un Maximo limpio del mismo source que VM1 Se crea un sistema externo que se llama PREMISES. Se testea con el intclient y se utilizan distintos ficheros XML para comprobar el funcionamiento. El primero de ellos para crear un Asset, y el segundo para introducir meters del asset. Al introducir las meters del asset, no se muestra ningún error ni en el servlet, ni en las colas. Página 185

194 7. Conclusiones Durante el desarrollo de este proyecto, se han adquirido un conjunto de conocimientos, así como una serie de conclusiones, las cuales se pueden dividir principalmente en dos bloques: Desde el punto de vista tecnológico: o o o o o o o Aprendizaje de nuevas tecnologías emergentes, el impacto que tienen en España y en el resto de Europa. Cómo estas nuevas tecnologías pueden solucionar tareas muy tediosas al solucionarlas de forma manual, o como tradicionalmente se venían solucionando. Incursión en nuevas plataformas de desarrollo. Independientemente de lo anterior, dado al aprendizaje autodidacta en algunas áreas del proyecto, se ha observado que actualmente hay una gran cantidad de estándares para cualquier tecnología, y la tendencia es cada vez más a estandarizar todo, paradójicamente, como cada cosa se estandariza de la forma que cada empresa ve conveniente, da la sensación que esa estandarización va hacia atrás, ocasionando en ocasiones una des estandarización. Importancia de desarrollar un software de calidad. Importancia de documentar correctamente cada paso que se va dando, puesto que, en caso contrario, dado un proyecto de las magnitudes del presente, es muy difícil volver a puntos que se habían dado y no se habían documentado. Búsqueda de información en entornos donde bien la información es escasa o es demasiada. Esto se debe a que en el momento del lanzamiento del proyecto, IBM había comprado MRO recientemente, esto significaba que la documentación existente en IBM sobre Maximo era muy confusa, y por supuesto, escasa. Por otra parte, a la mitad del desarrollo del proyecto, IBM saca al mercado el Premises Server 6.1, lo que significa que todo el estudio de arquitectura de Premises 6.0 y anteriores se echa a perder debido al gran cambio que supone la migración a esta nueva versión. A su vez, la Página 186

195 documentación existente de Premises Server 6.1 es nula, con un mayor impacto en aquella documentación relativa a aspectos de bajo nivel. o Aprendizaje de las distintas familias de software de IBM. A nivel personal: o Incursión en la vida profesional, ya que este proyecto se ha llevado a cabo gracias a la colaboración de becas de IBM S.A. con la Universidad Pontificia Comillas. o Toma de contacto con una multinacional del nivel de IBM. Forma de trabajar, proyectos, etc o Aplicación de los distintos conocimientos adquiridos en la carrera, viendo la utilidad práctica de los mismos. o Plantear y estudiar evaluar soluciones para poder decidir la que mejor se adapte a las necesidades y requisitos de los usuarios. o Experiencia de comenzar y desarrollar un proyecto real completamente desde cero. o Satisfacción de la utilidad del sistema, y que el mismo se vaya a utilizar. o Documentar y justificar el proyecto. Dar razones y motivos de porqué se ha seguido un cierto hilo de ejecución. o La capacidad de análisis es tal vez una de las más importantes, ya que permite obtener una información útil de toda la información obtenida. o Satisfacción por haber tenido la oportunidad de haber podido participar en un proyecto con un grado de innovación bastante elevado. Página 187

196 8. Bibliografía Para llevar a cabo este proyecto, se ha consultado la siguiente bibliografía: Libros [MOZO05] Javier L. de los Mozos Quiroga, Ramón Martínez Marín RFI Servicios Avanzados M2M, IBM Global Services España S.A., [CHAM06] James Chamberlain, Corinne Blanchard, Sam Burlingame, Sarika Chandramohan, Eric Forestier, Gary Griffith, Mary Lou Mazzara, Subu Musti, Sung-Ik Son, Glenn Stump, Christoph Weiss IBM WebSphere RFID HandBook. A Solution Guide, IBM Redbooks, [CHAM06] James Chamberlain, Corinne Blanchard, Sam Burlingame, Sarika Chandramohan, Eric Forestier, Gary Griffith, Mary Lou Mazzara, Subu Musti, Sung-Ik Son, Glenn Stump, Christoph Weiss IBM WebSphere RFID HandBook. A Programming Guide, IBM Redbooks, [IBMC08] [IBMC07] [IBMC07] [IBMC07] [IBMC07] [IBMC07] [IBMC07] International Business Machines Corporation WebSphere Premises Server Information Server, IBM Information Center, International Business Machines Corporation WebSphere RFID Premises Server Installation Guide, Version , IBM Corporation, International Business Machines Corporation IBM Tivoli Maximo Installation Guide Microsoft Windows IBM WebSphere, IBM Corporation, International Business Machines Corporation IBM Tivoli Maximo System Administrator Guide, IBM Corporation, International Business Machines Corporation IBM Tivoli Maximo Technical Reference Guide, IBM Corporation, International Business Machines Corporation IBM Tivoli Maximo User Guide, IBM Corporation, International Business Machines Corporation IBM Tivoli Maximo Enterprise Adapter System Administrator s Guide, IBM Corporation, Página 188

197 [IBMC07] [IBMC07] [BARR01] International Business Machines Corporation IBM Tivoli Maximo for Transportation Installation Guide, IBM Corporation, International Business Machines Corporation IBM Tivoli Maximo for Transportation Maximo User s Guide Addendum, IBM Corporation, Jesús Barranco de Areba Metodología del Análisis estructurado de sistemas, Universidad Pontificia Comillas, Madrid [ECKE02] Bruce Eckel Piensa en Java, Segunda edición, Prentice Hall, Madrid [BERG03] Hans Bergsten JavaServer Pages, 3 rd Edition, O REILLY Páginas Web o Wikipedia: La enciclopedia libre o IBM Sensors and actuators 03.ibm.com/solutions/businesssolutions/sensors/index.jsp o Maximo Asset Management ibm.com/software/tivoli/products/maximo-asset-mgmt/ o Gartner Inc, Magic Quadrant for Enterprise Adapter article19/pdf/article19.pdf o Maximo Asset Management InfoCenter c=/com.ibm.itmaxam.doc/welcome.htm o DeveloperWorks: Tivoli Maximo o Premises Server 6.1 InfoCenter Página 189

198 ANEXO I ANEXO I. Instalación Premises v6.1 Página 1

199 ANEXO I 1. Verificar los siguientes requisitos de hardware y software: a. Hardware b. Software i. Requisitos mínimos: 1. Procesador: Intel Pentium 4 a 3.0 GHz 2. Memoria: 2 GB 3. Espacio libre en disco: 8 GB 4. Espacio libre en disco temporal para la instalación: 500 MB i. Sistema Operativo ii. Browsers iii. Middleware 1. Windows: Windows Server 2003 Standard or Enterprise editions with Service Pack 2, or Windows Server 2003 R2 Standard or Enterprise editions with Service Pack 2 2. Linux: SUSE LINUX Enterprise Server (SLES) V9.3 (Kernel 2.6) 1. Es necesario disponer de un explorador web con JavaScript activado. Los browsers soportados son Internet Explorer 6.0 y Mozilla Firefox 1. WebSphere Application Server IBM HTTP Server WebSphere MQ DB2 for Linux, UNIX, and Windows Enterprise edition or Oracle (10g driver) 2. Comprobar los siguientes prerrequisitos a. Configurar Internet Explorer i. En el navegador, Tools > Internet Options. Página 2

200 ANEXO I ii. Seleccionamos la pestaña de seguridad. Página 3

201 ANEXO I iii. Hacemos click en Custom Level iv. Nos dirigimos a Scripting > Active Scripting, y hacemos click en Enable. Página 4

202 ANEXO I v. Hacemos click en Ok, y otra vez en Ok. b. Configurar Mozilla Firefox i. En el explorador, navegar a Tools > Options. Página 5

203 ANEXO I ii. Seleccionamos Contenido. Página 6

204 ANEXO I iii. Activamos el check box de Enable JavaScript, y hacemos click en Ok. Página 7

205 ANEXO I 3. Instalación del WebSphere Premises Server Nota: Cuando se especifican los paths de instalación, asegurarse de que los directorios contienen únicamente caracteres ASCII de Inglés US. También introducir este formato de caracteres en los paths de directorios y en los ficheros de propiedades. Nota: Introducir passwords que cumplan las reglas de contraseñas de la máquina destino. Una contraseña incorrecta hará que la instalación falle. a. Comprobar los requisitos de hardware y de software como se especifica en el punto 1 de la instalación. b. Completar los prerrequisitos de software como se especifica en el punto 2 de la instalación. c. Si planeamos usar DB2 como el servidor de bases de datos, y queremos utilizar una base de datos existente, asegurarse de que la base de datos fue creada con la opción de permitir XML para la base de datos (Enable database for XML) Página 8

206 ANEXO I (El code set se fijará en UTF-8). Si la base de datos DB2 no fue creada con esta opción, será necesario borrarla y recrearla si queremos utilizarla. El instalador creará la base de datos, pero también existe la opción de instalar la base de datos manualmente también. Por defecto, utilizaremos esta opción, eso es debido a que en principio no utilizaremos una base de datos existente. d. Ejecutar el programa de instalación ubicado en el directorio sat_installer en la raíz del CD apropiado para el sistema operativo. Por defecto, Windows 2003 Server SP2 e. Leer el acuerdo de licencia y seleccionar el radio button correspondiente a I accept the terms of the license agreement message si aceptamos los términos del acuerdo de licencia. Posteriormente, hacemos click en Next. Página 9

207 ANEXO I f. Cuando aparece el panel de bienvenida, es posible: i. Hacer click en Next para seguir instalando el producto. ii. Cambiar los paths por defecto usados para el despliegue de paquetes (en prinicipio llevar a cabo la opción anterior). Página 10

208 ANEXO I g. En el panel de selección de tareas, hacer click en Next para instalar el producto y elegir el tipo de la base de datos. Página 11

209 ANEXO I h. Elegir utilizar DB2 como base de datos en local. Página 12

210 ANEXO I i. En caso de que no tengamos DB2 instalado en el servidor, el instalador lo hará, puesto que hemos seleccionado la opción de local. Si ya tuviésemos instalado el DB2, el instalador reconocerá que está instalado, por lo que habría que comprobar que los parámetros reconocidos son correctos. j. Elegir instalar WebSphere Premises Server y hacer click en Next. Página 13

211 ANEXO I k. Hacemos click en Next para instalar el Bundle Repository Server requerido. Página 14

212 ANEXO I l. En el panel de especificación de máquinas para el servidor de bases de datos, especificar la máquina de destino para DB2 (localhost) y hacer click en Next. Página 15

213 ANEXO I m. Opcionalmente, utilizar el botón para probar las conexiones para acceder a la base de datos y comprobar que la conexión se realiza de forma correcta. n. En la ventana de especificación de las máquinas de destino para el WebSphere Premises Server, especificar la máquina local (localhost) y hacer click en Next. Página 16

214 ANEXO I o. En la ventana de especificación del Bundle Repository Center, especificar como máquina localhost y hacer click en Next. Página 17

215 ANEXO I p. Introducir la información de configuración de la base de datos. Importante, marcar la casilla correspondiente a la opción de Create and populate tables con respuesta afirmativa. Página 18

216 ANEXO I Página 19

217 ANEXO I i. NOTA: Introducir una password que cumpla las reglas de passwords de la máquina destino. Una contraseña inválida causará que la instalación falle. q. Introducir la información necesaria para WebSphere MQ y hacer click en Next. i. Puesto que el ejemplo se está instalando en un sistema operativo Windows, nos pregunta el directorio de instalación del WebSphere MQ. Aceptar el directorio por defecto. ii. En caso de que la instalación se lleve a cabo en un sistema operativo Linux, se preguntará por la contraseña. r. Introducir la información correspondiente al WebSphere Application Server y hacer click en Next. Página 20

218 ANEXO I Página 21

219 ANEXO I i. Importante: Si contamos con una instalación previa de WebSphere Application Server con version o posterior (pero no la requerida, ), y deseamos que el instalador actualice la version del WebSphere Application Server, es necesario que el WebSphere Application Server esté parado antes de comenzar el despliegue de la instalación. ii. En caso de requerir seguridad para el WebSphere Application Server, hay que tener en cuenta que la seguridad del WebSphere Application Server no se activa por defecto en el instalador. Es necesario configurarla de forma adicional, aunque en el ejemplo no se necesitará. iii. Hay que asegurarse que el puerto que elegimos es el s. Introducir la información de configuración para el IBM HTTP Server y hacer click en Next. Página 22

220 ANEXO I t. Introducir el directorio de instalación para el WebSphere Premises Server. Página 23

221 ANEXO I u. Introducir la información de configuración para el Bundle Repository Server. Página 24

222 ANEXO I v. En la ventana de resumen, confirmar las opciones elegidas. Esta ventana proporciona una lista de todas las opciones seleccionadas y una estimación del tiempo necesario para la finalización de todas ellas. Página 25

223 ANEXO I w. Para iniciar la instalación y las tareas de configuración, hacer click en Deploy all. i. En caso de que únicamente deseemos iniciar una tarea específica, hacer click en Deploy task, pero asegurarse de que las tareas que se eligen están el el orden correcto. Por ejemplo, no es posible desplegar el WebSphere Premises Server antes del despliegue de DB2 si no contamos con la base de datos instalada. ii. Hacer click en Back para hacer cambios. Una vez que se inicia el despliegue, se cuenta con la opción de parar si es necesario parar el despliegue antes de que la instalación finalice. Una vez que se completan todas las tareas, la pantalla de estado de despliegue indica que el despliegue fue correcto. Página 26

224 ANEXO I x. Cuando se completa la instalación, comprobar los ficheros de logs con el fin de identificar posibles errores. Desde el asistente de despliegue es posible ver mensajes detallados o el log principal. Los logs se pueden encontrar en deployment_wizard_installation_dir/logs, donde deployment_wizard_installation_dir es la ubicación de instalación del asistente de despliegue. Los valores por defecto son los siguientes: i. C:\Program Files\SolutionFiles\logs ii. opt/solutionfiles/logs y. Cerrar la ventana para salir del asistente. Se mostrarán diversos mensajes: i. Una pregunta por si queremos guardar los cambios. Elegiremos no puesto que no queremos volver a ejecutar el asistente. En caso de querer volver a ejecutarlo, elegiremos la opción afirmativa. Página 27

225 ANEXO I ii. Un diálogo que pregunta si deseamos salir. Elegimos Yes para salir del asistente. iii. Una vez que la instalación se haya completado con éxito, el servidor debería contar con los siguientes productos instalados: iv. WebSphere Premises Server con su ubicación por defecto: 1. C:\Program Files\IBM\RFID 2. /opt/ibm/rfid v. WebSphere Application Server vi. WebSphere MQ vii. IBM HTTP Server viii. DB2 for Linux, UNIX, and Windows ix. el Bundle Repository Server (instalado localmente) x. La instalación crea también un repositorio de bundles en el directorio raíz de documentos en el servidor HTTP, IHS_HOME\htdocs\en_US\bundles. Por ejemplo, el path para un sistema operativo Windows podría ser C:\Program Files\IBM HTTP Server\htdocs\en_US\bundles. Este repositorio almacena todas las aplicaciones para el OSGi Equinox para la gestión del Bundle Repository Server. 4. Pasos de Post-instalación En caso de ver errores en la instalación, comprobar la siguiente página web para resoluciones posibles del problema. doc_6.1.0/ts_common.html Página 28

226 ANEXO I a. Asegurarse que la variable de entorno WAS_HOME está fijada al directorio de instalación del WebSphere Applicatoin Server. Los directorios de instalación por defecto del WebSphere Application Server son: i. C:\Program Files\IBM\WebSphere\AppServer ii. /opt/ibm/websphere/appserver Importante: En caso de haber desplegado el WebSphere Premises Server en remoto, la salida debería ser el servidor de destino. b. Asegurarse que están especificados correctamente los paths de los ficheros para las edge alerts y los heartbeat en el fichero de propiedades premises.properties. Página 29

227 ANEXO I c. Asegurarse que el filtro de borrado para el Data Capture and Delivery está fijado correctamente en el fichero de propiedades premises.properties file. See Setting the delete filter for Data Capture and Delivery. d. Asegurarse que los queue Managers IBM RFID y DC se están ejecutando. i. Abrir el WebSphere MQ explorer y buscar IBM.RFID.QM e IBM.DC.QM en la carpeta Queue Managers. Si existen flechas verdes al lado de cada gestor de colas, entonces significan que se están ejecutando. ii. Ejecutar el comando dspmq en /opt/mqm/bin. Este comando informará del estado actual del queue manager. Página 30

228 ANEXO I e. Asegurarse de que todas las aplicaciones del WebSphere Application Server se están ejecutando. Abrir la consola administrativa del WebSphere Application Server, expandir aplicaciones y hacer click en Enterprise Applications. Las aplicaciones siguientes deberían aparecer con una flecha verde cerca de ellas: i. AMITJ2EE ii. IBM_Bundles_Management Nota: En caso de haber instalado el Bundle Repository Server en remoto, es posible que no se muestre la aplicación anterior. iii. IBM_EPCIS_Adapter iv. IBM_Premises_DockDoorApp v. IBM_Premises_PVSConsole vi. IBM_Premises_Server vii. IBM_Premises_Server_BIRT viii. IBM_SensorEvent_Engine Página 31

229 ANEXO I f. Abrir la consola administrativa del WebSphere Premises Server para verificar que es accesible. Página 32

230 ANEXO I g. Comprobar los ficheros de log del WebSphere Application Server y del WebSphere Premises Server en busca de algún error. h. Editar el fichero de configuración config.ini en el directorio IBM_RFID_HOME\dts\configuration y actualizar el código siguiente con los puertos y nombres correspondientes. com.ibm.rfid.bundle.list.url= dle?name= Server_name/bundles/bundlelists/dc_rdrsim4dts.txt El puerto por defecto es i. Editar el fichero dc_rdrsim4dts.txt y modificar el nombre correcto del host en la línea siguiente: PREFIX j. Iniciar el servicio Data Transformation manualmente. i. Comprobar si el Data Transformation fue iniciado como un servicio, y en ese caso, pararlo. Página 33

231 ANEXO I 1. Parar el servicio yendo a Start > Control Panel > Administrative tools > Services. Seleccionar IBM WebSphere Premises Server DT Service y hacer click en Stop. 2. Ejecutar el comando ibm_dts_service stop en el directorio IBM_RFID_HOME/dt. ii. Iniciar el Data Transformation utilizando el script. 1. En Windows, ejecutar el fichero dts.bat en el directorio IBM_RFID_HOME/dts. Página 34

232 ANEXO I 2. En linux, ejecutar el fichero dts.sh en el directorio IBM_RFID_HOME/dts. Estos comandos inician el Data Transformation service y muestran una consola del Data Transformation. k. Iniciar el bundle com.ibm.rfid.bundle.loader_version. i. Desde la ventana de commandos del Data Transformation en la ventana donde iniciamos el Data Transformation, ejecutar el commando ss para listar los bundles instalados. Se muestra la lista de bundles, incluyendo su ID, estado y nombre de cada bundle. ii. Identificar el ID de com.ibm.rfid.bundle.loader_version y ejecutar start ID_number. Página 35

233 ANEXO I l. Comprobar los ficheros de log en busca de posibles fallos en la carga de los bundles. m. Ejecutar los siguientes comandos para mejorar el rendimiento de la base de datos: db2 connect to IBMRFID db2 update database configuration using locklist immediate db2 update database configuration using maxlocks 95 immediate db2 update database configuration using maxappls 75 immediate db2 update database configuration using avg_appls 40 immediate db2 alter bufferpool IBMDEFAULTBP immediate size Página 36

234 ANEXO I n. Verificar la instalación del WebSphere Premises Server utilizando la utilidad del simulated reader en la consola administrativa. Elegir R2 como lector simulado. Página 37

235 ANEXO II ANEXO II. Instalación Maximo v6.2.1 Página 1

236 ANEXO II Seguir estos pasos para llevar a cabo la instalación de Maximo. Durante este proceso, se completarán las tareas en el orden siguiente: 1. Instalación del WebSphere Application Server 2. Instalación del Actuate Application Server 3. Instalación de Maximo 4. Instalación de las utilidades de idioma de Maximo 5. Instalación de los Products Enablers 6. Creación del esquema de Maximo 7. Despliegue de los ficheros EAR 8. Instalación de la Actuate Encyclopedia para Maximo 9. Log en el Maximo Start Center A continuación se muestra una figura con el orden de instalación de los paquetes que componen Maximo. 1. Necesitamos tener un disco con al menos 15 GB libres. En caso contrario, crearemos uno nuevo. 2. Instalamos el DB2 (C99XLNA). Este software es la versión Fix Pack 4 o v8.1 Fix Pack 11. En la página de los fix packs de IBM se refieren siempre a los fix pack con relación a la versión 8.1, por lo que en adelante se referirá a todos los Fix Packs como la versión 8.1. Página 2

237 ANEXO II Página 3

238 ANEXO II Página 4

239 ANEXO II Página 5

240 ANEXO II Página 6

241 ANEXO II Página 7

242 ANEXO II 2.1. Instalamos el Fix Pack 14 para el Workgroup Server Unlimited Edition (FP14_WR21377_WSE.exe) 3. Instalamos el WebSphere Application Server Network Deployment v6.0 for windows (C103FML.iso) 3.1. Hacemos login en Windows con una cuenta con permisos administrativos Introducimos el CD con el WebSphere Application Server. Si la instalación no comienza, hacemos doble click en launchpad.bat 3.3. En la ventana del launchpad, hacemos click en Launch the installation wizard for WebSphere Application Server 3.4. Hacemos click en siguiente Página 8

243 ANEXO II 3.5. Aceptamos el acuerdo de licencia 3.6. Dejamos que compruebe los prerrequisitos y hacemos click en siguiente Página 9

244 ANEXO II 3.7. Introducimos el directorio de instalación del WAS. (Se recomienda instalarlo en C:\IBM\WebSphere\AppServer eliminando el Archivos de programa o program files, debido a que posteriormente es posible encontrar errores por exceder el número de caracteres permitidos en la ruta) Página 10

245 ANEXO II 3.8. Para mejorar el rendimiento, no instalaremos los ejemplos del WAS. También deseleccionaremos la instalación de los javadocs Comprobamos el resumen de instalación y hacemos click en siguiente Página 11

246 ANEXO II Una vez completada la instalación, marcamos la casilla de Iniciar el asistente de creación de perfiles y hacemos click en siguiente En la pantalla en la que se nos pregunta por el tipo de perfil que deseamos crear, seleccionamos Crear un perfil de despliegue (Create a deployment manager profile) Página 12

247 ANEXO II Aceptamos el nombre que nos sugiere por defecto y hacemos click en siguiente Aceptamos la ruta sugerida de instalación del perfil Página 13

248 ANEXO II Aceptamos el nombre del nodo, célula y sistema principal que se nos sugiere por defecto Revisamos los puertos que se nos asignan por defecto y hacemos click en siguiente Página 14

249 ANEXO II Aceptamos los valores por defecto de la iniciación del perfil como un servicio de Windows Revisamos el resumen de la instalación y hacemos click en siguiente. En este momento, se pondrá a crear y configurar el perfil. Página 15

250 ANEXO II Una vez que ha terminado, nos aseguramos de que esté marcada la casilla de Iniciar la consola Primeros pasos y hacemos click en finalizar Hacemos click en Verificación de la instalación Página 16

251 ANEXO II Esperamos a que termine y comprobamos que la verificación se ha completado con éxito y cerramos la ventana. Página 17

252 ANEXO II En la pantalla de primeros pasos, haremos click en Asistente de creación de perfiles Página 18

253 ANEXO II Cuando se nos pregunte qué tipo de perfil deseamos crear, hacemos click en Crear un perfil Personalizado Página 19

254 ANEXO II Aceptamos los valores por defecto de nombre de sistema y puerto Página 20

255 ANEXO II Aceptamos el valor por defecto del nombre del perfil Aceptamos el valor de la ruta de instalación por defecto Página 21

256 ANEXO II Dejamos por defecto tanto el nombre del nodo como del sistema principal que se nos sugiere en la instalación Los puertos los dejamos por defecto Página 22

257 ANEXO II Revisamos el resumen de la instalación y hacemos click en siguiente Una vez que hemos terminado, nos aseguramos de que está marcada la casilla de primeros pasos Página 23

258 ANEXO II Cerramos todas las ventanas 4. Instalamos ahora el IBM Http Server 4.1. En el launchpad del WAS, hacemos click en iniciar el asistente de instalación de IBM Http Server Página 24

259 ANEXO II 4.2. Hacemos click en Siguiente 4.3. Aceptamos los términos del acuerdo de licencia Página 25

260 ANEXO II 4.4. Seleccionamos el directorio de instalación 4.5. Seleccionamos una instalación típica Página 26

261 ANEXO II 4.6. Aceptamos los valores que se nos sugieren para la iniciaión del HTTP Server, rellenando la contraseña si fuera necesario 4.7. Comprobamos el resumen de la instalación y hacemos click en siguiente Página 27

262 ANEXO II 4.8. Nos aseguramos de que esté marcada la casilla de iniciar WebSphere Application Server- Instalación de plug-in 4.9. Antes de instalar el plugin, pararemos los procesos del Node Agent y el Network Deployment <INSTALACIÓN_WAS>\profiles\Custom01\bin y ejecutamos stopnode.bat Página 28

263 ANEXO II Inicio Todos los programas IBM WebSphere Application Server Network Deployment v6 Profiles Dmgr01 Detener el gestor de despliegue Una vez están parados estos dos procesos, desmarcamos las dos casillas del asistente Página 29

264 ANEXO II Aceptamos los términos de licencia y hacemos click en siguiente Hacemos click en siguiente dentro de la ventana de prerrequisitos Página 30

265 ANEXO II Seleccionamos IBM HTTP Server V6 y hacemos click en siguiente Seleccionamos el escenario de máquina local Página 31

266 ANEXO II Introducimos la ruta de instalación para los plugins Seleccionamos la ubicación de instalación del WAS Página 32

267 ANEXO II Seleccionamos el archivo httpd.conf del servidor http y hacemos click en siguiente Aceptamos el nombre por defecto del servidor web y hacemos click en siguiente Página 33

268 ANEXO II Aceptamos la ruta del archivo plugin-cfg.xml y hacemos click en siguiente Aceptamos el resumen de instalación y hacemos click en siguiente Página 34

269 ANEXO II Aceptamos todos los diálogos siguientes (información) y finalizamos el asistente. Página 35

270 ANEXO II Iniciamos el Node Agent y el Network Deployment Página 36

271 ANEXO II Para completar la instalación del plugin, abrimos una ventana de consola y nos dirigimos a la ruta de instalación de plugins /../IBM/WebSphere/Plugins/bin Página 37

272 ANEXO II Ejecutamos configurewebserver1.bat Esperamos hasta que se nos muestre Configuration save is complete Paramos de nuevo el node agent y el network deployment 5. Procedemos a instalar las actualizaciones del WAS y del servidor http Instalamos primero el refresh pack para el WAS (v6.0.2) (C103KML) 5.2. Hacemos un backup de la configuración del WAS antes de instalar el refresh pack Ejecutamos vía consola el fichero backupconfig.bat en cada uno de los perfiles que creamos anteriormente Borramos la carpeta updateinstaller si estuviera presente en la ubicación <path_to>/ibm/websphere/appserver Página 38

273 ANEXO II 5.4. Descomprimimos el fichero 6_0_WS_WAS_WINX32_RP ZIP en el directorio especificado en el paso anterior Una vez descomprimido correctamente, ejecutamos dentro de update installer el fichero update.exe 5.6. Aceptamos el directorio de instalación del plugin que se nos muestra por defecto 5.7. Seleccionamos la opción Instalar paquete de mantenimiento 5.8. Aceptamos el nombre del archivo del paquete de mantenimiento por defecto y procedemos a la instalación 5.9. Se copiará el JDK y nos pedirá reiniciar el asistente Aceptamos todos los dialogos del asistente de nuevo y esperamos a que se termine la instalación. Página 39

274 ANEXO II Instalamos de forma análoga el refresh pack para el HTTP Server y para el plugin web NOTA: Para el plugin, la ubicación donde deberemos copiar la carpeta updateinstaller es <path to>/ibm/websphere/plugins Página 40

275 ANEXO II Ahora procedemos a la instalación de los fix packs del WAS, del HTTP server y del plugin. La instalación es igual a la del refresh pack. El CD de instalación es C103WML Página 41

276 ANEXO II Página 42

277 ANEXO II Página 43

278 ANEXO II NOTA: También hay que instalar después del fix pack del WAS, IHS y el plugin (en ese órden), el fix pack para el Java SDK. El proceso de instalación es el mismo Página 44

279 ANEXO II y la carpeta updateinstaller tiene que ubicarse en el directorio AppServer del WAS. 6. Instalación del Actuate iserver (Se omite, puesto que no se utilizará) 7. Instalación de Maximo 7.1. Seleccionamos el idioma de instalación y hacemos click en OK Hacemos click en siguiente en la pantalla de bienvenida Página 45

280 ANEXO II 7.3. Seleccionamos el servidor de aplicaciones. En este caso es IBM WebSphere 7.4. Introducimos el número de serie Página 46

281 ANEXO II 7.5. Seleccionamos el directorio de instalación (Por defecto, C:\Maximo) 7.6. Seleccionamos el servidor de bases de datos que utilizaremos con Maximo. En este caso, seleccionamos DB Introducimos los siguientes parámetros de configuración de la base de datos Database Server name: localhost Database port Number: Database Name: MXES Database Username: Maximo Password for Database User: Maximo 7.8. Dejamos en blanco el servidor SMTP 7.9. Dejamos también en blanco los s que aparecen Dejamos por defecto los valores del servidor de aplicaciones Activamos la casilla Enable Maximo Enterprise Adapter Dejamos por defecto el nombre del servidor Hacemos click en siguiente en la pantalla actual, puesto que no utilizaremos el Actuate Dejamos la siguiente pantalla por defecto y hacemos click en Siguiente Hacemos click en siguiente cuando se nos muestra la pantalla posterior Página 47

282 ANEXO II Revisamos los parámetros de instalación y hacemos click en Install Una vez que se ha instalado, hacemos click en siguiente Desmarcamos la casilla de buscar actualizaciones y hacemos click en siguiente Desmarcamos la casilla de crear una cuenta en el servicio de asistencia técnica en línea y hacemos click en terminado 8. Ejecutamos el product updater 8.1. Ejecutamos el archivo max621upd.exe 8.2. Indicamos el directorio donde instalamos Maximo y hacemos click en siguiente 8.3. Verificamos el resumen de instalación y hacemos click en install 8.4. Cuando termine la instalación satisfactoriamente, hacemos click en Done 8.5. Nos movemos a la carpeta <Maximo_root>\applications\maximo y ejecutamos el fichero version.bat. El resultado ha de ser algo como Maximo Application Server Build 156 DB Build V Parametrizamos algunos valores de Maximo 9.1. Navegamos a la carpeta <Maximo_root>\applications\activeportal\WEBINF\classes\com\actuate\Exte rnaltext 9.2. Abrimos el fichero actuatei18ntext.properties, y verificamos que los valores correspondan con los siguientes Página 48

283 ANEXO II 9.3. Añadimos en la propiedad actuate.externtext.password= la contraseña del usuario de base de datos que especificamos previamente 9.4. Buscamos la siguiente cadena: l_reportlabel.columnwidth as width1 from.reportlabel y añadimos el nombre del esquema de la base de datos tal y como se muestra a continuación: l_reportlabel.columnwidth as width1 from Maximo.reportlabel Maximo 9.5. Buscamos la cadena actuate.externtext.localesqlstring=select varvalue from y añadimos al final de la línea, el nombre del dueño del esquema de la base de datos: actuate.externtext.localesqlstring=select varvalue from Maximo 9.6. Pegamos una copia del fichero actuatei18ntext.properties en la siguiente carpeta: <Maximo_root>\applications\activeportal\WEBINF\classes\com\actuate\Exte rnaltext 10. Instalación de las utilidades de idioma Insertamos el cd de instalación de las utilidades de idioma de maximo, primero el de Español (C102FES) Ejecutamos el fichero maxlang.exe Seleccionamos el idioma deseado en la lista que se muestra y hacemos click en OK Hacemos click en siguiente Página 49

284 ANEXO II Introducimos la ruta de instalación de Maximo Página 50

285 ANEXO II Verificamos el resumen de instalación y hacemos click en siguiente Marcamos la casilla de generar el fichero maximohelp.ear y hacemos click en siguiente Repetimos los pasos anteriores para instalar todas las utilidades de idioma. 11. Instalación de los product enablers Introducimos el CD correspondiente al product enabler que deseemos instalar (C1074ML), y ejecutamos el archivo setup.exe Página 51

286 ANEXO II Después de seleccionar el idioma, hacemos click en siguiente Introducimos el directorio de instalación de Maximo Página 52

287 ANEXO II Hacemos click en instalar, y esperamos a que la instalación finalice Cuando haya creado los.ear correspondientes, hacemos click en finalizar 12. Creación del esquema de Bases de datos Creamos una base de datos con el mismo nombre que dimos en pasos anteriores. MXES. El comando es db2 create database MXES Abrimos una ventana de diálogo de DB2 y nos movemos al directorio BND de DB2, donde ejecutamos los siguientes comandos: db2 bind db2schema.bnd db2 clipkg Abrimos el db2 command center Herramientas de Administración General Centro de Control Todas las Bases de Datos Crear Base de Datos Estándar Sobre MXES, vamos a Buffer Pools o Agrupaciones de almacenamientos intermedios y crearemos los siguientes buffer pools de 32 KB MXESBUFPOOL, tamaño de página de 32KB: Creamos los siguientes tablespaces adicionales utilizando es espacio gestionado por la base de datos. Creamos los contenedores como MXES.DBF Y MXESSYSTMP.DBF MXES, de tipo normal y seleccionamos el Bufferpool MXESBUFPOOL Página 53

288 ANEXO II MXESSYSTMP, de tipo temporal y seleccionamos el bufferpool MXESBUFPOOL Ajustamos los siguientes parámetros en la base de datos LOGFILSIZ 1024 APP_CTL_HEAP_SZ APPHEAPSZ 1024 También es posible omitir estos pasos, escribiendo los siguientes comandos en una consola de MSDOS. echo null > index.dat echo null > maximo.dat echo null > syscat.dat echo null > systemp.dat echo null > users.dat CREATE DATABASE MXES ON 'C:' ALIAS MXES USING CODESET UTF-8 TERRITORY EN COLLATE USING SYSTEM CATALOG TABLESPACE MANAGED BY DATABASE USING ( FILE 'C:\DB2\MXES\syscat.dat' ) USER TABLESPACE MANAGED BY DATABASE USING ( FILE 'C:\DB2\MXES\users.dat' ) TEMPORARY TABLESPACE MANAGED BY DATABASE USING ( FILE 'C:\DB2\MXES\systemp.dat' ) WITH 'MXES'; CREATE BUFFERPOOL BUFF32 IMMEDIATE SIZE PAGESIZE 32 K ; CREATE BUFFERPOOL BUFF4 IMMEDIATE SIZE PAGESIZE 4 K ; ALTER BUFFERPOOL IBMDEFAULTBP SIZE 702; CREATE REGULAR TABLESPACE MXES PAGESIZE 32 K MANAGED BY DATABASE USING ( FILE 'C:\DB2\MXES\maximo.dat' ) EXTENTSIZE 16 OVERHEAD 10.5 PREFETCHSIZE 16 TRANSFERRATE 0.14 BUFFERPOOL BUFF32 DROPPED TABLE RECOVERY OFF; COMMENT ON TABLESPACE MXES IS 'MXES'; CREATE REGULAR TABLESPACE INDX PAGESIZE 32 K MANAGED BY DATABASE USING ( FILE 'C:\DB2\MXES\index.dat' ) EXTENTSIZE 16 OVERHEAD 10.5 PREFETCHSIZE 16 TRANSFERRATE 0.14 BUFFERPOOL BUFF32 DROPPED TABLE RECOVERY OFF; COMMENT ON TABLESPACE INDX IS 'indx'; CREATE SYSTEM TEMPORARY TABLESPACE TEMP PAGESIZE 32 K MANAGED BY DATABASE USING ( FILE 'C:\DB2\MXES\systemp1.dat' ) EXTENTSIZE 16 OVERHEAD 10.5 PREFETCHSIZE 16 TRANSFERRATE 0.14 BUFFERPOOL BUFF32 ; ALTER TABLESPACE SYSCATSPACE BUFFERPOOL BUFF4; ALTER TABLESPACE TEMPSPACE1 BUFFERPOOL BUFF4; ALTER TABLESPACE USERSPACE1 BUFFERPOOL BUFF4; GRANT DBADM,CREATETAB,BINDADD,CONNECT,CREATE_NOT_FENCED_ROUTINE,IMPLICIT_SCH Página 54

289 ANEXO II EMA,LOAD,CREATE_EXTERNAL_ROUTINE,QUIESCE_CONNECT ON DATABASE TO USER MAXIMO; GRANT DBADM,CREATETAB,BINDADD,CONNECT,CREATE_NOT_FENCED_ROUTINE,IMPLICIT_SCH EMA,LOAD,CREATE_EXTERNAL_ROUTINE,QUIESCE_CONNECT ON DATABASE TO GROUP DB2ADMNS; cd \ cd C:\IBM\SQLLIB\BND\ db2 bind db2schema.bnd db2 clipkg cd C:\IBM\SQLLIB\BIN\ db2text ENABLE DATABASE FOR TEXT CONNECT TO MXES UPDATE DATABASE CONFIGURATION FOR MXES USING APP_CTL_HEAP_SZ 3000; UPDATE DATABASE CONFIGURATION FOR MXES USING APPGROUP_MEM_SZ 11514; UPDATE DATABASE CONFIGURATION FOR MXES USING CATALOGCACHE_SZ 260; UPDATE DATABASE CONFIGURATION FOR MXES USING CHNGPGS_THRESH 50; UPDATE DATABASE CONFIGURATION FOR MXES USING DBHEAP 1413; UPDATE DATABASE CONFIGURATION FOR MXES USING LOCKLIST 1000; UPDATE DATABASE CONFIGURATION FOR MXES USING LOGBUFSZ 132; UPDATE DATABASE CONFIGURATION FOR MXES USING LOGFILSIZ 20000; UPDATE DATABASE CONFIGURATION FOR MXES USING LOGPRIMARY 20; UPDATE DATABASE CONFIGURATION FOR MXES USING LOGSECOND 0; UPDATE DATABASE CONFIGURATION FOR MXES USING MAXAPPLS 40 MAXLOCKS 77; UPDATE DATABASE CONFIGURATION FOR MXES USING MINCOMMIT 1; UPDATE DATABASE CONFIGURATION FOR MXES USING NUM_IOCLEANERS 1; UPDATE DATABASE CONFIGURATION FOR MXES USING NUM_IOSERVERS 3; UPDATE DATABASE CONFIGURATION FOR MXES USING PCKCACHESZ 604; UPDATE DATABASE CONFIGURATION FOR MXES USING SOFTMAX 105; UPDATE DATABASE CONFIGURATION FOR MXES USING SORTHEAP 898; UPDATE DATABASE CONFIGURATION FOR MXES USING STMTHEAP 2048; UPDATE DATABASE CONFIGURATION FOR MXES USING DFT_DEGREE 1; UPDATE DATABASE CONFIGURATION FOR MXES USING DFT_PREFETCH_SZ 32; UPDATE DATABASE CONFIGURATION FOR MXES USING UTIL_HEAP_SZ 84509; UPDATE DATABASE MANAGER CONFIGURATION USING SHEAPTHRES 17971; UPDATE DATABASE MANAGER CONFIGURATION USING INTRA_PARALLEL OFF; UPDATE DATABASE MANAGER CONFIGURATION USING MAX_QUERYDEGREE 1; UPDATE DATABASE MANAGER CONFIGURATION USING MAXAGENTS 400; UPDATE DATABASE MANAGER CONFIGURATION USING NUM_POOLAGENTS 400; UPDATE DATABASE MANAGER CONFIGURATION USING NUM_INITAGENTS 0; UPDATE DATABASE MANAGER CONFIGURATION USING FCM_NUM_BUFFERS 4096; UPDATE DATABASE MANAGER CONFIGURATION USING PRIV_MEM_THRESH 32767; SET CURRENT QUERY OPTIMIZATION = 5; Reiniciamos la base de datos para que los cambios tengan efecto Hacemos un backup de la base de datos recién creada, por si la instalación de Maximo falla no tener que volver a parametrizarla Página 55

290 ANEXO II Ejecutamos el script maxinst -sindx tmxes ubicado en la carpeta <MAXIMO_HOME>\tools\maximo y esperamos a que la instalación finalice Ejecutamos el script <Maximo_home>\tools\maximo\importlang_es.bat Repetimos estos pasos para las utilidades de idioma en Inglés (obviamente, el script a ejecutar en el paso es importlang_en.bat) 13. Creamos un servicio de Windows para el Node Agent Abrimos una ventana de MSDOS Cambiamos el directorio a C:\IBM\WebSphere\AppServer\bin Escribimos el siguiente comando sin saltos de línea (sensible a mayúsculas y minúsculas) WASService -add NodeAgent -servername nodeagent profilepath "C:\IBM\WebSphere\AppServer\profiles\Custom01" washome "C:\IBM\WebSphere\AppServer" logroot "C:\IBM\WebSphere\AppServer\profiles\Custom01\logs\nodeagent" LogFile "C:\IBM\WebSphere\AppServer\profiles\Custom01\logs\nodeagent\startServ er.log" -restart true Página 56

291 ANEXO II 14. Despliegue de la aplicación Arrancamos los perfiles Custom01 y Dmgr01 del WAS Una vez arrancados, abrimos una ventana de Internet Explorer y abrimos la dirección Página 57

292 ANEXO II Dentro de servidores, elegimos Servidores de Aplicaciones Página 58

293 ANEXO II Hacemos click en Nuevo Especificamos un nombre, en el ejemplo MAXIMOSERVER, y hacemos click en siguiente Página 59

294 ANEXO II Aceptamos todas las pantallas por defecto y le damos a siguiente, hasta llegar a Fin. Página 60

295 ANEXO II Página 61

296 ANEXO II Marcamos la casilla al lado de MAXIMOSERVER y hacemos click en Guardar Marcamos Sincronizar cambios con nodos y hacemos click en Guardar Página 62

297 ANEXO II Cuando se termine, hacemos click en Aceptar Desde la pantalla principal, dentro de Servidores, hacemos click en Servidores de aplicaciones Hacemos click sobre el servidor que hemos creado, MAXIMOSERVER Página 63

298 ANEXO II Desplegamos el grupo Java y gestión de procesos, dentro de Infraestructura del servidor Hacemos click en Definición de proceso Página 64

299 ANEXO II En la pantalla que se nos muestra, hacemos click en Máquina virtual Java Página 65

300 ANEXO II Bajamos y escribimos 512 para Tamaño de almacenamiento dinámico inicial y 1024 para Tamaño máximo del almacenamiento dinámico, y hacemos click en Aplicar Página 66

301 ANEXO II Hacemos click en Guardar Página 67

302 ANEXO II Nos aseguramos de que la casilla de Sincronizar cambios con nodos esté marcada, y hacemos click en Guardar Página 68

303 ANEXO II Desde Servidores de aplicaciones > MAXIMOSERVER > Java y gestión de procesos > Definición de proceso > Máquina Virtual Java, hacemos click en Propiedades personalizadas Página 69

304 ANEXO II Hacemos click en Nuevo Página 70

305 ANEXO II Rellenamos con los valores siguientes, y hacemos click en aceptar Nombre: com.ibm.websphere.sendredirect.compliance Valor: Descripción: Redirect for Actuate Hacemos click en Guardar y sincronizamos con los nodos Página 71

306 ANEXO II Especificamos los puertos HTTP: Dentro de Servidores > Servidores de aplicación> MAXIMOSERVER, desplegamos el grupo Valores del contenedor Web, dentro de Valores del contenedor Página 72

307 ANEXO II Hacemos click en Cadenas de transporte de contenedor Web Página 73

308 ANEXO II Hacemos click en Nuevo y especificamos como nombre de la cadena de transporte MAXIMOTRANSPORT Nombre del puerto: MAXIMO, Sistema principal: * Puerto 9081 Página 74

309 ANEXO II Aceptamos y finalizamos la creación de la cadena de transporte Página 75

310 ANEXO II Guardamos y sincronizamos los cambios con los nodos Creamos un Host Virtual Expandimos el grupo Entorno Hacemos click en Sistemas principales virtuales Hacemos click en Nuevo Nombre: MAXIMOSERVER_host Página 76

311 ANEXO II Aplicamos, hacemos click en guardar y sincronizamos los cambios Hacemos click en MAXIMOSERVER_host Página 77

312 ANEXO II Hacemos click en Alias de sistema principal Hacemos click en Nuevo Aceptamos los valores por defecto (Nombre del sistema principal * y puerto 80) Hacemos click en Aceptar (No guardar todavía) Hacemos click en Nuevo Página 78

313 ANEXO II Especificamos ahora el puerto que escribimos en el punto (9081), y hacemos click en Aplicar Página 79

314 ANEXO II Guardamos y sincronizamos Configuramos las colas JMS para el MEA Hacemos click en Service integration > Buses Hacemos click en Nuevo Introducimos los siguientes valores Nombre: meajmsbus Deshabilitamos la casilla de seguridad Cambiamos el valor de High message threshold a mensajes Hacemos click en Aplicar Desde la consola administrativa del WAS, hacemos click en Service integration > Buses Hacemos click en el bus creado previamente, meajmsbus Dentro de Topology, hacemos click en Bus members En el diálogo que se muestra, hacemos click en Add Hacemos click en Next Hacemos click en Finish Hacemos click en Save. Nos aseguramos que está marcada la casilla de sincronizar cambios con nodos Configuramos los valores JMS para el MEA Hacemos click en Buses dentro de Service integration para crear el bus de destino JMS para la cola continua Hacemos click en meajmsbus Hacemos click en Destinations dentro de Destination resources Hacemos click en New para crear un nuevo destino Marcamos la opción Queue Como identificador, introducimos cqinbd y como descripción, Continuous Queue Inbound y hacemos click en Next Aceptamos las pantallas por defecto y en el resumen de destinos, hacemos click sobre cqinbd Cambiamos el valor de Maximum failed deliveries a 1 y como el destino por defecto de excepciones, marcamos None Hacemos click en Apply, guardamos y sincronizamos los cambios con los nodos. Página 80

315 ANEXO II Volvemos a ir a Service integration > Buses > meajmsbus para crear el destino de la cola secuencial Hacemos click en Destinations y posteriormente en New para crear el nuevo destino En Identifier introducimos sqinbd y como descripción, Sequential Queue Inbound Repetimos los pasos previos para colocar el valor de Maximum failed deliveries a 1 y el destino de las excepciones a None en la cola sqinbd Repetimos los pasos para crear la cola de salida sqoutbd con descripción Sequential Queue Outbound y los mismos valores que las colas anteriores Hacemos click en Resources > JMS Providers > Default Messaging para crear el MEA Connection Factory Hacemos click en Browse nodes Seleccionamos el nodo (no el Cell Manager) Hacemos click en Queue Connection Factory Hacemos click en New e introducimos los siguientes valores Name meaconfact JNDI name jms/mro/int/qcf/intqcf Bus name meajmsbus Guardamos y sincronizamos los cambios con los nodos Hacemos click en Resources > JMS Providers > Default messaging Dentro de Destinations, hacemos click en JMS queue Creamos una cola nueva con los siguientes valores Name cqin JNDI name jms/mro/int/queues/cqin Bus name meajmsbus Queue name cqinbd Hacemos click en OK y guardamos y sincronizamos los cambios con los nodos Repetimos los pasos anteriores para crear otra cola con los siguientes valores Name sqin JNDI name jms/mro/int/queues/sqin Página 81

316 ANEXO II Bus name meajmsbus Queue name sqinbd Repetimos los pasos anteriores para crear una última cola con los valores que se muestran a continuación Name sqout JNDI name jms/mro/int/queues/sqout Bus name meajmsbus Queue name sqoutbd Hacemos click en JMS Providers > Default messaging para crear el Activation Specification de la cola continua, puesto que debe ser activada antes de poder recibir mensajes Hacemos click en JMS activation specification Hacemos click en New e introducimos los siguientes valores Name meajmsact JNDI name meajmsact Destination type Queue (default) Destination JNDI name jms/mro/int/queues/cqin Bus name meajmsbus Maximum batch size Maximum concurrent endpoints Hacemos click en OK guardamos y sincronizamos los cambios Reiniciamos el servidor para que los cambios tengan efecto Despliegue de los.ear Expandimos el grupo Aplicaciones, y hacemos click en Instalar una aplicación Página 82

317 ANEXO II Seleccionamos Sistema de archivos local y examinamos el fichero maximo.ear, que se encuentra en <MAXIMO_HOME>\deployment\default, y hacemos click en Siguiente Página 83

318 ANEXO II Marcamos Generar enlaces por omisión y hacemos click en Siguiente Página 84

319 ANEXO II Aceptamos los valores por defecto y hacemos click en Siguiente Seleccionamos todos los módulos, y dentro de la caja Clústeres y servidores, seleccionamos únicamente MAXIMOSERVER, hacemos click en Aplicar y en Siguiente Página 85

320 ANEXO II Aceptamos los valores por defecto hasta el paso 7 y hacemos click en siguiente Página 86

321 ANEXO II Seleccionamos todos los módulos web, y seleccionamos en todos MAXIMOSERVER_host Seguimos aceptando los ajustes por defecto Esperamos a que se complete el proceso y hacemos click en Guardar en configuración maestra Página 87

322 ANEXO II Sincronizamos los cambios con los nodos Repetimos estos pasos para desplegar maximohelp.ear y acweb.ear Expandimos el grupo Servidores y hacemos click en Servidores de Aplicaciones Página 88

323 ANEXO II Seleccionamos MAXIMOSERVER y hacemos click en Iniciar. Esperamos hasta que aparezca una flecha verde Página 89