Integración de SAP y Aplicaciones Legadas a Través de SOA
Professor Advisor
dc.contributor.advisor
Bastarrica Piñeyro, María Cecilia
es_CL
Author
dc.contributor.author
Díaz Puentes, Alfredo Andrés
es_CL
Staff editor
dc.contributor.editor
Facultad de Ciencias Físicas y Matemáticas
es_CL
Staff editor
dc.contributor.editor
Departamento de Ciencias de la Computación
es_CL
Associate professor
dc.contributor.other
Ochoa Delorenzi, Sergio
Associate professor
dc.contributor.other
Casanova Araya, María Cecilia
Admission date
dc.date.accessioned
2012-09-12T18:19:03Z
Available date
dc.date.available
2012-09-12T18:19:03Z
Publication date
dc.date.issued
2008
es_CL
Identifier
dc.identifier.uri
https://repositorio.uchile.cl/handle/2250/104945
Abstract
dc.description.abstract
El objetivo general del presente trabajo de título es un caso real de integración entre el ERP
de SAP y los legacy del área de logística de una compañía distribuidora de combustible en Chile
utilizando los principios que el patrón de diseño SOA ofrece y con la ayuda de herramientas
comerciales que implementan y facilitan la integración entre sistemas computacionales
heterogéneos. El área de logística de la compañía cuenta con una variedad de aplicaciones
legacy Web del tipo J2EE que utilizan de manera independiente y que les permiten realizar la
programación de los pedidos de combustible que sus clientes efectúan, asignación de los
pedidos a los distintos camiones tanques, modificaciones y cancelaciones que se deban realizar
a los pedidos, medición de eficiencia de los transportes y viajes efectuados, etc.
La integración se basó en los conceptos que el patrón SOA indica como mejor práctica con la
ayuda de plataformas tecnológicas de la línea WebSphere de IBM tales como MessageBroker,
MQ, Adaptadores del MessageBroker para comunicarse con el ERP y con el sistema operativo
sobre el cual funciona que es Os/400 sobre iSeries, etc. Las principales decisiones tomadas
durante el proyecto dicen relación con casos en los cuales se decidió hacer pasar el flujo de
datos por la plataforma SOA instalada y cuando no hacerlo porque entregaba mejores
prestaciones, tiempos de respuesta y seguridad. Durante todo el proyecto estos fueron temas
de discusión y análisis dado que cada caso en la práctica trae un análisis individual que debe ser
enfrentado bajo la mirada de conveniencia para la empresa, entendiéndose que estas
conveniencias podrían ser tiempos de respuesta, puntos de falla, servicio e imagen al cliente.
En el detalle del trabajo se tomaron decisiones relacionadas con el tipo y formato de
mensajes que transportan los datos entre las aplicaciones que participan del proceso de
despacho de combustibles. Detalles como saber cuántos campos de datos son necesarios por
mensaje, que separadores debían acordarse y ser utilizados, como serían tratados los
encolamientos de los mensajes según si prioridad, los mensajes devuelta que deben ser
enviados para cerrar los ciclos de cada proceso que se gatillen, etc. Cada una de estas
decisiones en los distintos mensajes de datos que se gatillan en cualquier sentido dentro del
proceso de despacho de combustible muestra los esfuerzos principales sobre los cuales se
concentró el presente trabajo de título.
El resultado final fue un conjunto de aplicaciones del tipo Web y legacy que se comunican
con el ERP de SAP para lograr de manera exitosa el despacho de combustible desde las plantas
de la compañía; todo esto con la ayuda de una infraestructura conformada por filesystem y
carpetas compartidas, plataformas de integración de IBM, flujo de mensajes que transmiten los
datos, etc. Se concluye que los proyectos de integración si bien logran el objetivo principal
sobre el cual se basan, carecen aún de la madurez necesaria en su diseño o bien en los
productos comerciales que existen hoy en el mercado, dado que muchas decisiones se debieron
tomar descartando lo que eran las mejores prácticas de SOA en beneficio de obtener una
solución acorde a las necesidades de la compañía. La mirada de performance y eficiencia de los
procesos es muy difícil dimensionarla y considerarla durante este tipo de proyectos y deben ser
enfrentados, por lo general, posteriormente a su puesta en marcha, cuando los datos
cuantitativos del funcionamiento entregan muchos más antecedentes que ayuden a encontrar
las oportunidades de mejoras y los cuellos de botella que deben ser solucionados.