PPT 1:

Un servicio se aloja en un servidor y en general, un servicio corresponde

a un conjunto de funcionalidades de un sistema que pueden ser
reutilizadas.
Que es integrar?
1. Unir sistemas para que pasen a formar parte de un sistema
completo.
2. Hacer que distintos sistemas conversen e interacten entre ellos
para producir un resultado de manera transparente para el usuario.
Porque integrar?
-Procesos transparentes de comunicacin e intercambio de datos
-Interoperabilidad de sistemas
-Automatizacin de procesos
-Disponibilidad de informacin
-Uso ms eficiente del software
Ventajas de integrar:
1) Muy caro reprogramar todo
Adems conlleva un alto riesgo de que el nuevo sistema no funcione
2) Es ineficiente reinventar la rueda
Sistemas actuales ya resuelven el problema
3) Velocidad de desarrollo < Velocidad del negocio
Cuando el software est listo ya no se necesita
El problema de la integracin se puede reducir a dos soluciones:
Botar lo existente y reemplazar por soluciones completamente
integradas.
Integrar sistemas de tal manera que los ya existentes se comuniquen
entre si.
PPT2:
SOAP
Basado en xml
Es independiente del lenguaje en que se implemente
Es neutral con respecto a la capa de transporte (http, smtp, etc)
Composicin:
SOAP-ENV Evelope: Identifica al xml como un mensaje SOAP
SOAP-ENV Header: Cabecera identificando namespaces u otra
informacin opcional
SOAP-ENV Body: Contiene operacin, parmetros y respuesta a la
llamada

WSDL: contrato entre proveedor y cliente del servicio

Documento xml que describe
Ubicacin del servicio
Operaciones del servicio
Parmetros de las operaciones
Objetos de las operaciones (parmetros y respuestas)
Casos de uso:
-Comunicacin con tipos de datos establecidos
-Se requiere publicar servicios de manera estndar para que otros los
consuman
-Implementacin muy rpida (especialmente en lenguajes fuertemente
tipeados)
-Servidor mantiene seciones
REST:
Usado principalmente en web
Es independiente del lenguaje en que se implemente
Stateless
No existe una sesin entre request. Cada mensaje contiene toda la
informacin necesaria para invocar al servicio
Cacheable
Clientes pueden dejar respuestas en cache. Por lo mismos, las
respuestas deben definir si son cacheables o no para prevenir errores de
los clientes
Servidor por capas
El cliente no debe distinguir si est conectado al sistema final o a un
intermediario
Idempotente
Una misma llamada produce siempre el mismo resultado en el servidor
(sin efectos colaterales)
La respuesta misma puede cambiar debido a que un recurso puede
haber cambiado de estado entre los requests
Interfaz uniforme
Recursos son manipulados usando (a lo menos) 4 operaciones
estndar
Operaciones
GET: obtener recurso (seguro)
POST: Pasa un recurso de un estado a otro
PUT: Crea un nuevo recurso (idempotente)
DELETE: Borra un recurso (idempotente)
Cdigos de respuesta (todos los cdigos aqui) 200 OK
404 Not Found

 500 Internal Server Error

Mensajes son auto-descriptivos
Casos de uso:
-Ideal para aplicaciones/APIs web
-Comunicacin entre cliente/servidor en que no se requiera manejar
sesiones (autenticacin se envia en cada mensaje)
-Servicios livianos con poco overhead
APIS:
Una Api es un conjunto de funcionalidades pensadas para ser utilizadas
por otro software
Permiten la integracin entre distintos programas
Las apis pueden ser en mltiples formatos: SOAP, REST, WEB, etc
PPT 3:
SOA: SERVICE ORIENTED ARCHITECTURE
SOA no es solamente crear servicios con bajo acoplamiento, es
preocuparse del bosque en vez del rbol.
Lo ms importante es que la comunicacin es uno a uno y comienza
porque alguien solicita la informacin (el cliente). Es decir me comunico
con un servidor a la vez.
Como caracteristicas los servicios son de bajo acoplamiento, la
comunicacin es de punto a punto, comunicacin es iniciada por cliente
y la comunicacin es sincrona, es decir yo pido algo y espero hasta que
alguien me conteste
Proveedor
Funcin que brinda un servicio.
Consumidor o cliente
Funcin que consume el resultado del servicio provisto por un
proveedor.
Orquestacin
Secuenciar servicios y proveer lgica adicional para procesar datos.
Coordinar distintas llamadas a servicios.
Caractersticas:
-Servicios con bajo acoplamiento .
-Comunicacin punto a punto .
-Comunicacin iniciada por cliente .
-Comunicacin sincrona.
Principios de diseo de servicios:
1)Contratos de servicio estndares.
-Para servicios SOAP, archivos xml estandarizados.

-Para servicios REST, documentacin estandarizada.

-> Descubrimiento de servicios centralizada (directorio de servicios).
2)Bajo acoplamiento de servicios
3)Abstraccin de servicios: Los servicios esconden la lgica que realizan
de los clientes. El cliente quiere que se entregue el output esperado, no
le interesa el cmo.
4)Servicios son reutilizables
5)Servicios son autnomos: Un servicio tiene control sobre su ambiente
de ejecucin, lgica, bases de datos, etc, con el fin de que los resultados
entregados sean consistentes y confiables.
6)Servicios no deben tener estados: Una llamada no debe producir un
cambio de estado que pueda afectar a la llamada siguiente.
7)Composicin de servicios: Un problema grande puede ser separado en
mltiples problemas chicos, cada uno resuelto por un servicio diferente.
8)Interoperabilidad: Un servicio debe ser cliente- agnstico. Se deben
usar estndares que permitan su uso para que diversos clientes usen el
servicio.
NO Hacer:
-Interfaz expuesta en servicio
-Flexibilidad exagerada (Integers-Strings por ejemplo)
EDA: EVENT DRIVEN ARCHITECTURE
Una arquitectura EDA es cuando las acciones se realizan a medida que
suceden eventos o hechos trascendentales que gatillan una accin en un
sistema
Ejemplos: Mensajeria gatillada por emisores (whatsapp), deteccin de
fraudes, deteccin de terroristas en redes sociales, push-up notifications
Evento
Es un hecho que sucede en un software o hardware que produce un
cambio significativo de estado
Emisor
Agente que gatilla un evento
Suscriptores
Todos aquellos clientes que quieren recibir notificaciones de eventos
Notificar

 Accin de propagar el evento hacia los suscriptores

Caractersticas:
-Servicios con bajo acoplamiento
-Comunicacin entre mltiples sistemas
-Comunicacin iniciada por evento
-Comunicacin asincrona
Cuando los emisores detectan un cambio, lanzan un evento y notifican a
los suscriptores.
Tienen la responsabilidad de gatillar el evento pero no le interesa el
procesamiento del evento por parte de los suscriptores.
Una vez gatillado el evento, no espera respuesta por parte de los
suscriptores.
Por lo general, un evento debe contener:
Accin (que est pasando)
Timestamp (ya que procesamiento es asincrono)
Estado (otra informacin relevante del evento)
Los datos guardados en arquitecturas basadas en eventos suelen ser
mucho ms voluminosos que aquellos en arquitecturas de servicios, ya
que los eventos muestran la historia de un sistema mientras que los
servicios entregan el estado en un determinado momento.
Datos SOA vs Datos EDA

PPT 5:
Etapas para la integracin:
0) Kick-of
1) Evaluacin

-Definir objetivos -Estandarizar y definir parmetros -Comparar

alternativas
Entregables:
Se deben proponer distintas alternativas factibles y compararlas
Cuatro alternativas de integracin:
-Datos -Cdigo -Servicios -Interfaz
2) Diseo
Antes de construir la integracin, se deben disear las soluciones
iniciales para calcular los tiempos de desarrollos, recursos requeridos,
impacto, etc.
Entregables:
Recomendacin de implementacin de una de las soluciones iniciales
3)Decisin:
El encargado del proyecto debe decidir si realizar o no la integracin, y
en caso de que se realice, optar por una de todas las alternativas
propuestas.
A diferencia de las fases anteriores, esta corresponde a la
administracin, mientras que las anteriores son responsabilidad del
equipo tecnico, quienes entregan una recomendacin.
Conclusiones del proceso:
1)Definir un equipo de trabajo
2)Realizar una evaluacin y proceso por etapas
3)Involucrar a los usuarios
4)Separar intereses e interesados
5)Involucrar a la administracin, o a quien tome la decisin final
PPT 6:
Problemas de los Softwares actuales
-Se compran sistemas a medida que son necesarios sin ver el cuadro
completo
-No existe estrategia a largo plazo de TI
-Outsourcing de servicios TI dejan amarradas a las empresas al
proveedor
-Falta de documentacin y especializacin
Propuesta de la integracin:
-Una correcta integracin hace ms simple la migracin de sistemas
antiguos
-Al compartir los datos entre sistemas, los proveedores se hacen ms
prescindibles

Aproximaciones para la integracin:

1) Importacin y exportacin de datos: Copiar y pegar datos de un
sistema a otro. Informacin fluye de un sistema a otro pero la
integracin no aporta valor a los usuarios. Sirve para sistemas que no
tienen herramientas de integracin.
2) Integracin de aplicaciones cerradas: Sistemas propietarios que solo
se conectan con otros sistemas conocidos (de la misma suite/proveedor)
3)Integracin a nivel de datos: Se comparte una base o fuente de datos
comn. La dificultad de esta aproximacin es disear un modelo de
datos comn para dos aplicaciones. Es posible que cambios de datos
impliquen cambios de cdigo.
4)Integracin a nivel de cdigo: Unir dos cdigos fuentes de dos
aplicaciones diferentes y generar un solo sistema homogeneo.
Tipos de Integracin:
A) Por Datos: Integracin de BDs para compartir datos entre
aplicaciones. Se puede lograr mediante conexiones directas a las
distintas bds o mediante el uso de bds centrales.
B) Por Metodos: Integracin se realiza a nivel de lgica de negocios. En
este nivel se encuentra la integracin por medio de servicios.
C) Por Interfaz: Una sola interfaz de usuario para informacin de
mltiples sistemas. Forma que entrega mayor valor para el usuario pero
ms compleja de lograr. Se suele usar para operaciones de alto nivel.
PPT 7:
ESB: Enterprise Service Bus
Es un estilo de arquitectura de Integracin que permite la comunicacin
por medio de un bus comn que consiste en una variedad de conexiones
punto a punto entre proveedores y usuarios de servicios.
Funciones:
1) Invocacin: Capacidad de enviar requests y recibir responses
desde servicios y recursos integrados.
2) Ruteo: Es la habilidad para decidir el destino de un mensaje durante
su transporte. Esta caracteristica es esencial debido a que permite
desacoplar el origen del destino.
Ejemplos:
-Enviar mensaje a mltiples destinatarios
-Filtrar mensajes que no cumplan ciertos criterios
-Agregar/Separar mensajes

-Re-secuenciamiento de mensajes
3) Mediacin: Todas las transformaciones o traducciones que puede
tener un mensaje antes de llegar a su destino final. Estos cambios
pueden ser a nivel de trasporte, formato del mensaje o incluso
contenido.
4) Seguridad: Proveer una forma de mensajeria segura.
-Autenticacin
-Autorizacin
-Encriptacin/Desencriptacin
-Mediacin de seguridad: Para comunicacin con canales/dominios
externos
5) Adaptadores: Este mdulo sirve para conectar servicios provistos por
el ESB. Debe poder usar adaptadores estndar, asi cmo adaptadores
personalizados.
6) Administracin: Por ltimo, la mayoria de los ESB proveen una
interfaz de administracin para:
Estadisticas
Alertas
Auditorias
Monitoreo
Configuraciones
Deploys
PPT 11:
Porque integrar? Para aumentar el valor al usuario/organizacin
Procesos transparentes de comunicacin e intercambio de datos
Interoperabilidad de sistemas
Automatizacin de procesos
Disponibilidad de informacin
Uso ms eficiente del software
Otros:
En ambas opciones, el middleware o mdulo que realiza la integracin,
debe preocuparse del flujo de datos de un CRM al otro. Los datos deben
ser integrados, no migrados, debido a que durante el periodo de
transicin ambos sistemas deben funcionar al mismo tiempo. Es decir,
los cambios en un sistema deben ser reflejados en el otro, ya sea por
una estrategia master-slave o de replicacin.

i)Sincronizacin de datos

Puede ser realizada de dos formas: (a) replicacin, donde los datos entre
los dos sistemas son iguales o (b) master-slave, donde los datos de una
aplicacin mandan sobre la otra. Para este caso, el master siempre debe
ser el sistema antiguo ya que algunas aplicaciones an se encuentran
funcionando basndose en este sistema.
Sin duda la forma ms robusta de operacin es la forma b, ya que de
esta manera se continua operando con el sistema antiguo y el sistema
nuevo se utiliza slo para la visualizacin de la informacin y reporteria.
Una vez concluido el proceso de transicin, deberia apagarse el sistema
antiguo para comenzar a operar con Siebel.
La forma a de sincronizacin es correcta, pero conlleva un riesgo
operacional mayor (ya que se recibirian transacciones y cambios por
ambos sistemas) y es mucho ms dificil de implementar.
ii) Manejo de fallas:
Dada la importancia operacional del sistema, el CRM no puede dejar de
funcionar. De acuerdo al contexto entregado, el CRM antiguo se
encuentra operativo hace varios aos por lo que no deberia tener
problemas, y en caso de fallas, tener sus propios protocolos de
recuperacin.
En caso de fallas de Siebel, este debe ser desconectado y se debe
realizar una vuelta atrs al sistema antiguo. Esto slo se puede realizar
si la sincronizacin de datos es master-slave (manda CRM antiguo) o los
datos estn completamente replicados.
Para mitigar el riesgo de fallas, como se explica en el punto anterior,
toda la operacin durante el periodo de transicin deberia ser utilizando
el CRM antiguo, y el CRM nuevo deberia ser un espejo de los datos y
transacciones del CRM antiguo.
iii) Operacin de la organizacin:
El punto principal para esta arista del problema es identificar el desafio
para los trabajadores de la empresa, especialmente quienes operan con
el CRM dia a dia. Ellos sern los que sufrirn el mayor impacto por lo que
la empresa deberia dedicar grandes esfuerzos a la capacitacin de los
usuarios.
Por otro lado, con el fin de generar una mayor tolerancia a fallas de
parte de los clientes, se deberia realizar una campaa de marketing para
avisar del gran cambio a nivel de sistemas que viene y que debido a
este puede haber demoras en la atencin.
Por ltimo, el equipo de sistemas debe tener especial cuidado en el

monitoreo de los sistemas durante la transicin para poder prevenir

problemas antes de que estos escalen y terminen por botar todos los
otros sistemas de la empresa.

Explique que procesos de negocio actuales se podrian migrar al nuevo

ERP. (se puede asumir que SAP tiene todas las funcionalidades adjuntas
en la tabla 1)
-Se puede cambiar administracin del inventario. Para que sea manejado
a traves del ERP. Todos los movimientos de bodega se deberian hacer a
traves del ERP. * Manteniendo el sistema actual adems.
-El procesamiento de las OC se podrian procesar directamente por el
ERP (tiene toda la informacin del inventario). La recepcin de OC tiene
que hacerse de cualquier medio que llegue ftp, e-commerce y b2b.
-En caso que no exista producto, puede manejar la Produccin (MRP)
calculando la necesidad de insumos en base a la receta.
-Emisin de OC a los proveedores para comprar insumos de fabricacin,
dependiendo de la necesidad de compra calculada.
-El procesamiento y verificacin de la Facturacin (emisin y recepcin)
se podria hacer a traves del ERP y asi manejar toda la contabilidad de la
empresa.
En caso que no se pudiera utilizar un ESB. Que conexiones deberia
desarrollar? Cmo se realizaria la integracin punto a punto?
Deberian generarse varias conexiones punto a punto:
Algunas conexiones deberian ser: OC (en caso que se quiera seguir
utilizando) Sii Banco E-commerce Mdulo orquestador que est

actualmente funcionando Ftp Stocks

Justifique, basndose en el punto anterior, la utilizacin de un ESB.
Diagrame como sera la nueva arquitectura del sistema. Qu sistemas
se podran dejar de utilizar? Qu conexiones de deberan desarrollar en
el ESB?
1)Se puede eliminar el mdulo orquestador desarrollado por los grupos.
Todos los procesos y conexiones se pueden hacer a traves del ESB.
2)Esto es conveniente por mltiples razones. No se tiene una
arquitectura espagueti. Bajo acoplamiento, menores costos de
mantencin, integracin de sistemas legados de forma transparente,
etc..
3)Se podria dejar de utilizar el sistema de OC, Odoo y el mdulo central
desarrollado por los grupos que hoy acta de coordinador entre los
distintos sistemas. Eventualmente se podria eliminar